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
reported.
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
reported?
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