Symlinks support status?
Dov Feldstern
dfeldstern at fastimap.com
Sun Nov 4 20:48:56 UTC 2007
Mark A. Flacy wrote:
> On 2007.11.04 10:43, Dov Feldstern wrote:
>> The original post is
>> here:http://permalink.gmane.org/gmane.comp.version-control.mercurial.general/3527
>>
>> The idea is basically to have the working directory appear --- to
>> all the usual tools (compiler, editor, etc.) --- as it would on
>> a symlink-supporting system, i.e., the contents of the symlinks look
>> like the contents of the linked-to files.
>
> Well, it *wouldn't* look the same without additional metadata and smarts.
>
Of course not. In the original post linked to above I go into more
detail explaining how I would like to see this work.
My idea for handling this is for a symlink to be replaced in the working
directory by an actual copy of the linked-to file/directory. Then it
"looks" the same as long as changes are not made to any of the copies.
Next, in order to keep all copies (and the linked-to original) in sync
if changes *are* made, there would be a command "hg symlinks" which
would update the symlinks: if a change was made to only a single copy,
then it would be propagated to all other copies. If different changes
were made to different copies, then a merge would be necessary, not very
different than a merge between the same file on two separate branches.
(This is part of the reason why I think that this kind of symlink
support belongs in a version control system.) As a first stage, perhaps
it would just be enough to require the user to manually move all the
changes to only a single copy.
Finally, when committing back to the repository, so firstly, a commit is
not allowed until all copies are synced (it's easy to check this, and
the actual syncing can be done with "hg symlinks"). And secondly, the
changes themselves are committed only to the linked-to file.
> You'd have two copies of the same file in two different places; the
> symlink may be simply a convenience feature of some type.
>
> ClearCase, for example, will create copies of the symlinked files in
> static views for file systems that don't support them. ClearCase treats
> the two copies as hard-linked, as far as I can tell; checking one out
> leaves the other checked out too.
> Ah. NTFS supports hard links
> (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_hardlink.mspx?mfr=true),
> so that's probably how Rational handled it.
>
Well, the version of ClearCase that we have installed at work handles it
in an even simpler manner: symlinks are not supported at all: making a
change to one copy does not propagate to the others (at least not before
checking in; maybe after checking in it's propagated, though I'm not
sure about that, either...).
>
> I wonder if Mercurial supports hard links correctly. Maybe you could
> just use those instead.
>
Dov
More information about the Mercurial
mailing list