Duncan Murdoch wrote:
> On 5/25/2006 11:55 AM, Nico Kadel-Garcia wrote:
>> Jim Sheldon wrote:
>>> Hello everyone, this is my first post to this mailing list.
>>> I have encountered a problem at work where we user subversion for
>>> our software projects. The problem arises when the following
>>> occurs: 1. file1.txt is moved/renamed (using subversion commands, not
>>> local filesystem) on system A to file2.txt.
>>> 2. System B then makes changes to file1.txt and commits them.
>>> 3. System A runs 'svn update' before commiting its changes. file1.txt is
>>> retreived from the server with modifications from
>>> System B. At this point users of both System A and B have to communicate
>>> merge their changes into file2.txt.
>> This is why the ghods invented branches: so that System A and B can
>> each have their own branches, so they can each avoid stepping on
>> each other this way. Then when they're done, they merge their
>> changes back to the trunk.
> No, I think you misunderstood. This is simply a conflict between what
> happened on A and what happened on B. A deleted the file, B modified
> some lines in it. The net effect is that they have made incompatible
> changes to the file. I don't know what happens if A commits first,
> but if B commits first (the case Jim was talking about), this happens:
That's right. This is *UNAVOIDABLE* in cases where two people are working on
the same branch, except perhaps by locking the files to prevent anyone else
from editing it. It's inevitable, and the conflicts are best resolved by
hand, which is what will happen when one of the commits fail.
> When A updates:
> - the file is resurrected with B's changes in it, but no warning.
Unless there's a branch, in which case the change in file structure is
> When A commits:
> - the file is deleted, losing B's changes.
Unless there's a different branch, in which case the change in file
structure is reported.
> When A updates, svn should report it as a conflict that needs to be
> resolved before A is allowed to commit his delete.
> Duncan Murdoch
And with different branches, they are!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu May 25 22:59:28 2006