Symlinks support status?

Dov Feldstern dfeldstern at fastimap.com
Sun Nov 4 14:48:56 CST 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-devel mailing list