[PATCH 1 of 4] hgmerge: add new hgmerge package under mercurial

[Steve Borho]

On Tue, 2008-01-08 at 11:49 -0600, Matt Mackall wrote:
> 
> 
> > +def _is_mergeable(base, local, other):
> > +    ''' Are the files mergeable?
> > +    @return: Success?
> > +    '''
> > +    mergetypes = ('dos', 'unix', 'mac')
> > +
> > +    for eoltp in (local.eoltype, other.eoltype, base.eoltype):
> > +        if eoltp not in mergetypes:
> > +            return False
> 
> Hmmm. Don't really like this. Does it apply to user-defined tools?

I should have responded to this as well, since this was my code.

This routine is checked before all merges, unless the merge tool was
specified by a file filter.

None of the 3-way merge tools I tested could do anything sane with
symlinks or binary files.  They all had failure modes somewhere between
annoying and disasterous (simplemerge itself will backtrace on some
symlinks).  So hgmerge tried to catch those cases before invoking any
textual merge application.

For the file extension based tool selections, it assumes that the file
is likely to be binary so it bypasses the is_mergeable and simplemerge
steps entirely and just runs the specified tool.

I'm open for discussion on how implicit or explicit these checks needs
to be.  For instance, even merge tools that properly handle binary files
would probably get tripped up by symlinks.

-- 
Steve Borho (steve at borho.org)
http://www.borho.org/~steve/steve.asc
Key fingerprint = 2D08 E7CF B624 624C DE1F  E2E4 B0C2 5292 F2C6 2C8C