Duncan Murdoch wrote:
> 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.
Merges are interesting: Because the merge happens all at once, it's possible
to see, clearly, the distinctions between the two source trees, with the
changes all logged on the branch you are actually merging from, intead of
trying to sort out changes that have occurred behind your back on someone
else's branch.
> 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?
Both programmers should be updating from the trunk occasionally. Whoever is
ready to merge back to the trunk first, does so. Then the next update *from*
the trunk for the other programmer has the changes. If the "move" happens
first, well and good, the second programmer sees this re-arrangement of
their material occur and may have a conflict reported.
If the "move" happens second, then well and good, the changes have been
integrated to the trunk and back out to the second branch, and its results
can be monitored.
The problem seems to be in communication, and in sharing simultaneous
branches and failing to commit the changes when they occur, rather than much
later after additional changes have been made.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 26 21:35:04 2006