Symlinks support status?

Douglas Philips dgou at
Mon Nov 5 16:24:12 CST 2007

On 2007 Nov 5, at 3:30 PM, Dov Feldstern indited:
> Rather, I think that adding the kind of support I'm suggesting  
> would be a nice enhancement, which should not hurt anyone who  
> thinks that this entire issue is a non-issue (because presumably  
> they either don't use symlinks in their repositories, or else they  
> don't attempt to expand them on non-symlink-capable filesystems).

Well, I am concerned, because I would not want to have my symlinks  
affected if I happened to pull a tree onto a Windows box to work on  
some unrelated-to-symlink files.

And then there are the downstream cases, such as pulling to a Windows  
box, then pulling again later when the symlink has changed to be a  
different file... what if it is to a file outside of hg's control?  
and then that file is later added to the repository? And what if the  
faux copy file in the Windows system had changed? Force the merge to  
fail? That sounds like a pretty invasive change... What happens when  
more than one file symlinks to the same destination? How does that  
get managed?

While what you suggested seems innocuous enough at a high level, it  
has all the earmarkings of causing pain once all the corner cases are  
discovered, which, despite all my advocating for client 666 here, is  
not something I'm comfortable saying can be completely discovered up  
front, so the risk of a nasty surprise down the road is hard to weigh...

> I hear you. I still think it would be a nice feature, though, and I  
> disagree about it being beyond the scope of a VCS. After all, this  
> situation *does* hinder interoperability of mercurial between OSes,  
> and I think that my suggested solution is neither "way out" (it's  
> quite similar to how ClearCase deals with this in snapshot views),  
> nor terribly hard to implement (at least, not if we stick to  
> conflict identification --- without merge --- of copies of symlinks).

Well, I think the hinderance is that symlinks don't map to all the  
platforms, which has nothing to do with whether you "check out" code  
there with VCS-A, VCS-B, mercurial, or zip. Just because you use  
mercurial as a fancy unzip, doesn't make the underlying  
incompatibility mercurial's fault...
You could make the same argument: that having a unix executable check- 
ed in and not converted to a windows .exe hinders interoperability...  
After all, "symlinks" and "executables for Unix" are both alien to  
Windows in a way that can't really be solved. Except that for  
executables folks have already gotten over the incompatibility, but  
the symlink's siren song is more alluring, more tantalizing, because  
it seems to admit of a simple solution (see above for why I think  
there are nasty corner cases).

> So first of all, having worked at such a company, you probably also  
> know that it's not always easy to change work processes, so for now  
> I'm stuck with this situation. So the question for me becomes  
> whether or not I can use mercurial for what I want to do. That need  
> not interest anyone but me, but then again, there may be others  
> like me out there who would like to see this...

I am truly sorry for the rigidity of your situation, and I completely  
understand the pain of working on Windows, for it is a pain I also  

> Secondly, I would be happy to hear suggestions for alternative ways  
> to structure our projects (but I guess this would be off-topic...).  
> Again, not that I'll be able to change the way we do things  
> overnight, but if there really are superior alternatives, perhaps  
> I'll be able to slowly get things moving in that direction...

We could talk about that off-list if you like... it is very off-topic  


More information about the Mercurial-devel mailing list