Re: svnmerge script

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: svnmerge script

Chris AtLee
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: svnmerge script

Bugzilla from john@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: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...