Community
Participate
Working Groups
Build ID: 3.3.1.1 Steps To Reproduce: 1. Checkout an svn project 2. Change/Add a file 3. Add this file to a Change Set 4. Make repository unavailable or slow 5. Restart eclipse 6. Change Set gets initialized before the local resources are loaded More information: Problem: Change Sets can disappear from the SVN Synchronize view on restart when the repository is unavailable. Debugging: I think I have reduced the problem to the following: [ActiveChangeSet.init] 1. The Change Set is loaded from pref file. 2. Change Set files are compared to repository. 3. Change Set files that have no diffs are removed from Change Set. 4. If no files are left in the Change Set, the Change Set is removed. Subversive uses the following method in order to create its diff: [AbstractSVNSubscriber.getSyncInfo] 1. lazy fetch remote file information from cache 2. lazy fetch local file information from cache 3. compare local to remote and return sync information The problem here is that this method explicitly states that remote and local file information caches must be up to date, which may not be true here. As Eclipse starts, the Change Set and local file information are loaded in different threads. In my case, the local file information has not yet been fetched when the Change Set was added. The both files are marked IStateFilter.ST_NOTEXISTS, which [UpdateSyncInfo.calculateKind] interprets as IN_SYNC (remote: unversioned, local: notexits) This means all these files are removed from Change set, and therefore the Change Set itself. When the caches do fill up the modified files are added to the Synchronization view, but the Change Set is gone. Possible solutions: - Disable the Subversive local file cache - Force Subscriber.getDiff to wait for cache/loader - Force ActiveChangeSet.init to wait for cache/loader I submitted this on the Subversive bug list, but it could also be solved on Eclipse's side.
Fix will be available tomorrow.
Has the fix been submitted to the repository yet?
(In reply to comment #2) > Has the fix been submitted to the repository yet? Yes, the change contained in the file AbstractSVNSubscriber.java at revision 9662. http://dev.eclipse.org/svnroot/technology/org.eclipse.subversive/trunk/org.eclipse.team.svn.ui/src/org/eclipse/team/svn/ui/synchronize/AbstractSVNSubscriber.java