Chris AtLee wrote:
> On Thu, 2005-10-03 at 22:35 -0500, John Belmonte wrote:
>
>>Chris Morgan wrote:
>>
>>>We were wondering whether it would be productive to work on moving the
>>>svnmerge script into the subversion code to fill the hole of "merge
>>>tracking" in the roadmap. What kinds of opinions do people have about
>>>the svnmerge implementation vs. the vision for merge tracking as
>>>specified on the roadmap?
>>
>>svnmerge breaks down when you want to do bi-directional merges.
>>Briefly, there is a loss of information when you do an "svnmerge merge",
>>because the automatic merge is mixed together with any subsequent
>>changes you make before the commit (e.g. to resolve conflicts). To
>>support a bi-directional merge, you need to be able to separate those
>>two parts.
>
>
> Sorry, I'm a bit late to this party, but I just started looking at
> svnmerge for use in my company.
>
> Can you explain in a bit more detail why bi-directional merges break
> down?
>
> Thanks,
> Chris
When you merge two branches with svnmerge, the automatic merge happens
into your working copy, you resolve conflicts and make other necessary
changes, and finally you commit. Within that commit are two pieces of
information: 1) the changes that happened on the source branch and 2)
the local changes you make on top of that before committing. When you
merge back in the other direction, you only want the second item.
However, svnmerge doesn't keep the two separate, and will try to apply
both components.
If you understand the use cases of bi-directional merges, it's easy
enough to experiment with svnmerge and see the problem.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 27 03:50:25 2005