Fixed interruption of Auto Build by RefreshStatusCacheSchedulingRule by HBuender · Pull Request #70 · subclipse/subclipse · GitHub
Skip to content

Fixed interruption of Auto Build by RefreshStatusCacheSchedulingRule#70

Open
HBuender wants to merge 2 commits into
subclipse:masterfrom
HBuender:master
Open

Fixed interruption of Auto Build by RefreshStatusCacheSchedulingRule#70
HBuender wants to merge 2 commits into
subclipse:masterfrom
HBuender:master

Conversation

@HBuender

Copy link
Copy Markdown

Referring to the discussion
(https://groups.google.com/forum/#!topic/subclipse/Ntbl_SfxUrg) a fix is
provided to avoid the interruption of the auto build process by the
RefreshStatusCacheSchedulingRule.
By falling back to a MultiRule, the auto build is finished before the
status cache refresh is triggered.

Signed-off-by: HBuender hendrik.buender@googlemail.com

Referring to the discussion
(https://groups.google.com/forum/#!topic/subclipse/Ntbl_SfxUrg) a fix is
provided to avoid the interruption of the auto build process by the
RefreshStatusCacheSchedulingRule.
By falling back to a MultiRule, the auto build is finished before the
status cache refresh is triggered.

Signed-off-by: HBuender <hendrik.buender@googlemail.com>
@HBuender

Copy link
Copy Markdown
Author

@selsemore

Copy link
Copy Markdown
Contributor

Isn't the solution to this problem to wrap the process that modifies a lot of files in the Workspace in a WorkspaceModifyOperation so that the "Refresh SVN status cache" job will only be triggered once, at the end?

}

private class RefreshStatusCacheSchedulingRule implements ISchedulingRule {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do go back to using MultiRule then we should remove the private RefreshStatusCacheSchedulingRule class, as it will be no longer used.

SVNProviderPlugin.broadcastModificationStateChanges(resources);
}
}
}, new RefreshStatusCacheSchedulingRule(MultiRule.combine(projectArray)), false);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is basically undoing the 1a8bed9 change, which was made so that it would still be possible to save file changes in a project while a long running status cache update was going on. IMO, this fix needs to be done in a way that does not lose that functionality.

When scheduling status cache refresh job use a scheduling rule that prevents
other status cache refresh jobs from running at the same time for the same
project (for example, if some tool is making changes in the workspace without
wrapping the changes in a WorkspaceModifyOperation), but does not lock the
project (i.e., does not prevent saving project changes).

@markphip

Copy link
Copy Markdown
Contributor

Note that the 4.3.0 release includes a different approach to this by introducing a preference to toggle off this status refresh. Perhaps that will be the solution to use since it seems like there are otherwise conflicting requirements here.

@HBuender

Copy link
Copy Markdown
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants