[PATCH 0 of 2] symlink merge fixes

[Steve Borho]

On Tue, 2007-10-02 at 03:13 -0300, Alexis S. L. Carvalho wrote:
> Thus spake Steve Borho:
> > While improving support for symlinks and binary files in hgmerge.py, I
> > happened across two problems.
> > 
> > The first problem was that the code in mercurial/merge.py which emits
> > 'other' and 'base' versions of the file being merged will not emit
> > symlinks.  Instead it emits a small text file containing the versioned
> > symlink contents.  This is not bad, in and of itself, but there's no way
> > for the merge script to know if the actual revisioned file was a
> > symlink.  So that if the user choses to keep the "other" file, the merge
> > script knows to place a symlink there with the contents of "other",
> > rather than just copying the small text file.
> > 
> > The first patch provides environment variables for each of the three
> > files: HG_LOCAL_ISLINK, HG_OTHER_ISLINK, and HG_BASE_ISLINK.
> > 
> > The second problem was in the post-processing of merged files.
> > Mercurial tries to re-establish the executable status of the local file
> > after the merge by calling util.set_exec().  Unfortunately, this
> > function isn't symlink safe so it will modify the symlink target rather
> > than the symlink itself.  I wasn't sure whether it was safe to modify
> > set_exec(), so the second patch adds a check in the merge code to bypass
> > set_exec() if the new local file is a symlink.
> 
> It should be safe (and better) to change set_exec.
> 
> > Beyond these two patches, there's still at least one remaining problem
> > with symlink merging on platforms which don't support symlinks.  There
> > is no mechanism for the merge application to inform Mercurial that the
> > new local file is intended to be a symlink.  So today whenever you do a
> > merge on Windows that included symlinks, those symlinks will lose their
> > symlink tags and will become normal text files.
> 
> On (file)systems without symlinks the file will inherit the symlink flag
> from its first parent, so merging 2 symlinks should work fine.  Merging
> a symlink and a regular file could be a bit problematic...

Since my merge script devolves to a simple selection model (pick local
or other) when either of the merge candidates is a symlink or a binary
file, it seems we could catch most of the problematic cases by adding a
mechanism for the merge script to inform Mercurial that the 'other' file
was chosen and thus it should inherit the manifest hints of the second
parent.  Perhaps by reserving a special return value to indicate 'other
file chosen'.

> The same logic is applied to the exec bit.
> 
> Your first patch looks fine, but we'll probably want to add some kind of
> fileflags method (analogous to filenode) to changectx to avoid
> rebuilding all the manifests.

I wasn't sure who you implied by "we" here. :-)   Would you like me to
take a stab at this?

-- 
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