[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with multiple users moving and updating files

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-05-25 23:22:23 CEST

On 5/25/2006 4:58 PM, Nico Kadel-Garcia wrote:
> 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
>>>> the
>>>> 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
>>>> to
>>>> 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
> reported.
>> 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!

I don't see how different branches make any difference, assuming that at
some point A and B are going to want to merge their changes into a trunk.

Could you give more details on the final steps where both sets of
changes are merged into the trunk? I don't see where the error gets

To start, assume:

A and B each copy the trunk to a branch.
A renames a file and commits on his branch.
B edits the same file and commits on his branch.
Both switch back to the trunk, and merge their respective branches into
their working copies.

Now what should happen, so that they can be sure the conflict will be

Duncan Murdoch

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 25 23:23:38 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.