Community
Participate
Working Groups
I20111207-2118 Steps: 1. Go to Orbit repo :pserver:anonymous@dev.eclipse.org:/cvsroot/tools 2. Check Out As > org.junit 3. When asked for branch, refresh tags and pick one 4. From the same repo, Check Out As > org.hamcrest 5. When asked for branch, again refresh tags first => IS: all branches are shown, from org.junit and org.hamcrest => SHOULD BE: only branches from the latter should be shown It seems to be caused by bug 339990.
I'll try to investigate it ASAP
The problem is that fixing bug 339990 we assumed that having two cache entries: one for a module and second for its submodule is an error situation or at least extraneous. If we know that Branch1 is in "module1" we don't really need information that Branch1 is in "module1/submodule1", because the only place where we ask for it top modules. It occurs that it's not true. We try to keep as detailed information as possible and there are some places where we need this information for submodule. Based on this I found another way to reproduce bug 339990. You don't need to create new branch each time you want to reproduce it. All you need to do "Replace with -> Another branch or version" and then go to the repositories view. Anyway I think that the best way to fix bug 339990 is to revert the last fix and then leave the detailed paths in cache, but filter them in the repositories view.
Created attachment 209749 [details] fix This fix reverts fix for bug 339990 and changes as follows: * branches are still cached with detailed paths * in repositories view paths for branch are filtered: if we have a module and its submodule, the submodule will not be displayed * if we have a submodule in the view and hit "refresh branches" the submodule will be replaced with the module (but only in the view, submodule still stays in the cache) * I found out why previously we had to make an extra commit in tests to see tags: we where using "buildResources" instead of "addResources" and files wheren't added to the project and committed. Empty project doesn't store tags, because tags are stored only for files. I used addResources and now extra commit is not necessary.
Created attachment 209750 [details] mylyn/context/zip
Gosia do we have a regression test for the scenario from comment 0?
(In reply to comment #5) > Gosia do we have a regression test for the scenario from comment 0? No, I'll add it.
We had a talk with Tomek yesterday and we came to the conclusion that the only way to make it work 100% correctly is to change the way cache is build and rendered to the user. Right now cache does not take into the account fact that structure on the server is hierarchical. Paths in cache are added whenever the check for tags in given path is made, no meter where exactly are the tags found (if this is directly under given path, or deeper in the hierarchy).
Created attachment 211659 [details] Hierarchical cache fix This patch changes the cache structure to hierarchical and also changes the view to show only tagged CVS folders in the repository view. This version is not final as I am still working on jUnits to cover the various repository structures tagging.
Created attachment 211660 [details] mylyn/context/zip
While investigating this problem I also found that tags are not removed from cache if they where removed from the repository, see bug 372639.
Created attachment 211682 [details] Hierarchical cache + tests Added some tests.
Created attachment 211683 [details] mylyn/context/zip
(In reply to comment #11) > Created attachment 211682 [details] > Hierarchical cache + tests Pushed to Gerrit: https://git.eclipse.org/r/#/c/5175/
I opened Bug 372862 to address more extensive problems with cache and moved attachment 211682 [details] there. Hire we will solve only the current issue.
Fixed with 37e006cad45d19a55c35dcb0e0123333f8cacb6f
(In reply to comment #15) > Fixed with 37e006cad45d19a55c35dcb0e0123333f8cacb6f Sorry, wrong commit 9dc5b700ad5d2dc49a8ff00037ec8f5763cdc2b4
