On Thu, 28 Apr 2005 04:15 am, Timothy Cordner wrote:
> Not sure if this is implemented yet or if it is
> implemented and it's not working like I expected:
> 1. Joe and Charlie check out head of a repository.
> 2. Joe begins working on foo.java
> 3. Charlie begins working on foo.java as well, and
> decides it is misnamed and doesn't do 'foo' it does
> 'bar'.. so he changes code in foo... then
> refactor->renames the class 'foo' to 'bar'
> 4. Now Charlie commits his 'version' of the project.
> foo.java is gone and bar.java is added.
> 5. In the meantime.. Joe has made MAJOR changes to
> his snapshot's 'foo.java' file.. now.. when he is
> ready to commit.. he properly does his 'update' to get
> everyone elses changes in order to merge/resolve
> conflicts etc..
> Here's where the issue is... Joe does his update..
> but instead of getting to merge his code changes to
> foo.java with Charlie's code changes to foo.java
> (which is now bar.java), Joe now see's his foo.java as
> unversioned... and hey.. there's now a new file
> bar.java, but nothing to indicate to Joe that bar.java
> used to be foo.java. and any other file that
> referenced the class foo has been refactored to
> reference bar.. so when he commits.. no one is going
> to be referencing his class or his changes.. and they
> will not be 'merged' into the new bar.java.
> Shouldn't subclipse let you know that the file you
> edited was moved? or at least throw some kinda of
> warning.. or error.. otherwize on a large team..
> something will more than likely go unnoticed until too
This sounds like a known subversion `feature`. This was recently
dicussed on the subversion mailing lists. (check the threads at
There is also an subversion issue at
These describe the underlying problem better than I could.
It is probable possible for subclipse to detect that this has happened;
however the real fix should be in subversion.
Hope this helps
Received on Thu Apr 28 05:43:22 2005