Re: svnmerge script

[Chris AtLee <ca...@sidefx.com>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnmerge script

[John Belmonte <jo...@neggie.net>]

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