[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Using hgmerge with 1.5's interactive conflict resolution

From: Augie Fackler <durin42_at_gmail.com>
Date: 2007-10-25 05:00:11 CEST

On Oct 24, 2007, at 9:37 PM, Karl Fogel wrote:

> Augie Fackler <durin42@gmail.com> writes:
>> In using Mercurial I noticed that hgmerge pretty much rocks across
>> platforms for doing interactive merges, but the arguments it takes
>> are somewhat different than ours. As such, I made a python wrapper
>> for the hgmerge script, which is attached.
>
> Do you think we should just change our interface to match? Or is
> there something Mercurial-specific about hgmerge?

Short version: hgmerge does make one Mercurial-specific assumption
about merging and user data, so I don't think we should just adopt
their interface.

Long (more complicated) version: Part of me wants to just match their
interface, but on the other hand it's kind of messy. hgmerge takes
three arguments (local base other) and then just dumps the result of
the merge back into local. That doesn't work for us because under the
hood the interactive conflict resolution expects the results to go
into another file. We can't very well dump the results of the merge
into local because local can (and probably does for conflicts on
update) contain unversioned edits, whereas in mercurial merges always
happen between already-versioned files. I already considered that
while writing the interface for (l)aunch in the first place, but it
just feels a little too icky given the case of user edits in 'local'.

>
> -Karl

Augie

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 25 05:00:48 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.