Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 311647

Summary: Subversive is showing an incoming change for a commit that occurred while auto synchronization was running.
Product: [Technology] Subversive Reporter: Leo Dos Santos <leo.dos.santos>
Component: CoreAssignee: Igor Burilo <igor.burilo>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: a.gurov
Version: unspecified   
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:

Description Leo Dos Santos CLA 2010-05-04 20:43:04 EDT 
The SVN change set view is showing me an incoming change for a change set that I literally just committed from the same workspace. I have automatic synchronization turned on, which can sometimes take a while. In this case synchronization had started before I committed my files and then picked up the incoming change set at some point later.
Comment 1 Igor Burilo CLA 2010-06-29 07:03:39 EDT 
As I correctly understood you did the following:
1. schedule automatic synchronization in Synchronize view
2. automatic synchronization started but didn't find any incoming changes
3. commit some modified files
4. at some time latter you see the files you just committed as incoming changes which is wrong
If these are not your steps could you please provide more details how to reproduce the problem?
What Subversive version do you use?
Comment 2 Leo Dos Santos CLA 2010-06-29 12:31:16 EDT 
Yes, this was pretty much what happened. To note, the scheduled automatic synchronization was still in progress when I committed the files. I don't recall which version I was using because I'm on the weekly builds of Subversive and I update very regularly.
Comment 3 Igor Burilo CLA 2010-07-01 03:54:07 EDT 
Could you reproduce the problem and if you can please provide steps to reproduce it? I tried it in several case but failed to reproduce.
Comment 4 Leo Dos Santos CLA 2010-07-02 12:42:55 EDT 
I can remember running into this problem only once.
Comment 5 Alexander Gurov CLA 2014-09-22 11:42:04 EDT 
The situation happened because the working copy state was collected before the commit started, but the request was sent after the commit finished. It is indeed a rare case and may seem buggy, but it is unreasonable to block the whole working copy for each and any operation in progress no matter if it touches the resource or not and disregarding if it is read or modification access. So, it would be best to ignore the case, since if you do update for the resource it will go out of synchronize view without any errors or any unnecessary change to the working copy.