Community
Participate
Working Groups
CVS cache does not contain precise information about tags when projects are placed in submodules in the repository. 1. Refreshing tags for module stores all tags found in this module under this module path, even if the tags are really found in submodules 2. Even if we have a list of tags refreshed for submodule it gives us no information about tags in parent module. To get the list of tags for its parent we have to do separate a refresh for the parent. 3. Autorefresh files, like ".project" defined for submodule are not used when we are doing a refresh for parent module. 4. In consequence of 3. refreshing tags for a module in repository that contains projects as submodules results in doing a heavy CVS command of recurse log even if doing only few logs for .project files would be sufficient. This command is often so heavy that is killed by the CVS server. 5. Even if only one submodule has given branch, after refreshing tags for the parent module repository view suggests that all submodules have this branch. Only way to see which submodules really have this branch is to open every submodule and see which of them contain files.
Created attachment 211810 [details] Hierarchical cache This is patch moved from Bug 366016. Its review has been started on Gerrit: https://git.eclipse.org/r/#/c/5175/
(In reply to comment #1) > Its review has been started on Gerrit: > https://git.eclipse.org/r/#/c/5175/ That review no longer iterates over the fix for this bug. If you want to have it reviewed in Gerrit, please push it as a separate change.
(In reply to comment #2) > That review no longer iterates over the fix for this bug. If you want to have it > reviewed in Gerrit, please push it as a separate change. This is the new review: https://git.eclipse.org/r/#/c/5190/
Fixed with 78b06e932f107395de4ac4bad9a6113a78639766.
Not good: this patch destroys the feature to compare against (and replace from) dates (Replace/Compare With > Another Branch or Version..., then try to add a date).
Created attachment 214684 [details] Fix for returning dates The previous fix caused a regression. The problem was that repositoryRoot.getAllKnownTags(..) function before the fix returned also Dates and it was the base for building the tags tree. After the fix Dates where added and stored correctly, but they where not returned, thus they where not rendered on the tree. The fix is trivial, it just adds Dates to the list of returned tags. I also created a test for adding dates.
Comment on attachment 214684 [details] Fix for returning dates The fix is good and works well. Previously added dates show up again and new ones can be added. Regarding the code: Please replace Set tags = new HashSet(); tags.addAll(dateTags); with: Set tags = new HashSet(dateTags); This sets a higher initial capacity if needed, and the change is smaller.
Created attachment 214699 [details] Fix for returning dates v2
(In reply to comment #7) > Set tags = new HashSet(); > tags.addAll(dateTags); > > with: > > Set tags = new HashSet(dateTags); done in attachment 214699 [details].
(In reply to comment #8) > Created attachment 214699 [details] > Fix for returning dates v2 Pushed as 9a44f1060a78d560859b9e7774a25703b8b6c3d2. Thx Dani for finding it and Gosia for providing the fix.
Verified in I20120429-2000 that the feature from comment 5 has been restored.
Bug 361928 and Bug 361926 contain backports of this fix. They also need to be committed.
