[PATCH 0 of 2] symlink merge fixes

[Alexis S. L. Carvalho]

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

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.

Alexis