Community
Participate
Working Groups
STEPS TO REPRO: - consider you have a shared folder structure like the following /multiproject /multiproject/project1 /multiproject/project2 - let project1 and project2 be Eclipse projects - checkout /multiproject *using an external SVN client* (like TortoiseSVN) to a local folder (e.g.: c:\checkout\multiproject) - start Eclipse (assume we have Subversive with an SVN 1.7 or 1.8 connector - I'm using JavaHL 1.8 right now), do an "Import Existing Projects into Workspace", select c:\checkout\multiproject as the root folder for import, check both project1 and project2 and leave the check box "copy projects into workspace" UNCHECKED - Eclipse will create projects in the workspace, but their actual contents will still be in c:\checkout\multiproject - from the outside (e.g. using Explorer) create the folder c:\checkout\multiproject\project1\build - in Eclipse refresh project1: the build folder will appear as unversioned - with an external SVN client (e.g. TortoiseSVN), add c:\checkout\multiproject\project1\build to svn:ignore - in Eclipse refresh project1 EXPECTED BEHAVIOUR Eclipse realizes that project1/build is now ignored. ACTUAL BEHAVIOUR Eclipse still thinks that project1/build is an outgoing addition MY SUSPECT In the described scenario, the workspace metadata is in c:\checkout\multiproject\.svn, which is *not* contained within the c:\checkout\multiproject\project1 folder, which is the one Eclipse is scanning when I issue a refresh on project1. If this is the actual cause, it would explain many other little glitches I see regarding Subversive not refreshing its status when some operations are performed with an external SVN client, although the user issues a "refresh" on the involved projects. This is very annoying, the only workaround is to restart Eclipse. If my guess is not the actual cause, feel free to change the summary.
(In reply to Mauro Molinari from comment #0) Hello Mauro, Thank you for reporting it. The bug seems to be related to this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=430056 but not the same, so I'll think of a solution that will solve this problem too.
Hi Alexander, that seems to be very similar, indeed, however, citing your comment: >In order to solve the problem I've added a monitor that checks wc.db's last modification time and then reloads statuses if there were some changes. >Although the solution is not perfect since if the wc.db is not visible under the workspace root it still won't pick up state changes. I think I'm exactly in this situation: wc.db not being under the workspace root. >So, the most guaranteed way is not to modify working copy outside the workspace. Oh, yes, but in the real world this is not practical, because of reasons like: - sometimes an external tool might solve better (than Subversive) some specific problems (w.r.t. merging or conflict resolution or massive operations on files, etc. etc.) - developers are often used to other tools Interoperability between Subversive and native SVN clients have always been a strong plus of Subversive (as opposed to the Eclipse CVS client, for instance), so it would be a pity that one has to forgo it for just a refresh problem.
Fixed.
Great news, thank you Alexander!
