[PATCH 0 of 2] symlink merge fixes

Steve Borho steve at borho.org
Sun Sep 30 20:43:02 CDT 2007


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.

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.

Cheers,

--
Steve Borho


More information about the Mercurial-devel mailing list