Symlinks support status?
dgou at mac.com
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
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