Symlinks support status?
dfeldstern at fastimap.com
Mon Nov 5 14:01:25 CST 2007
Marcin Kasperski wrote:
>> 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.
> But when they are, we have the problem....
If you mean: "but when the copies *are* changed, we have a problem",
then I go on to explain how this can be dealt with.
> Plus, do not forget about cases like:
> variables.sh --> ../config/variables.sh
> appversion -> ../startups/appversion
> (well, a bit artificial, but I keep my /etc/ in mercurial and even
> more ugly configs are not that rare)
I don't see what the problem with this is. But now that you mention it,
there is one situation (maybe that's what you meant) which really *is* a
problem: cycles formed by the symlinks. E.g.: a/b at ->../a , which expands
to a/b/b/b/b/... . So yes, we would not be able to do anything about a
case like this, and we would have to have a mechanism to recognize
cycles and not even attempt to expand them...
> Also, in cases where symlinks point outside, they are often useless
> when moved to another system. What benefit it would bring if one
> worked really hard to support on Windows this symlink to
> /usr/local/share/icons ;-) ?
Yes, symlinks pointing outside are a different story. I'm trying to
figure out how we can map the repository to the working directory.
Anything that's not in the repository is beyond the scope of what I'm
> On the other hand: what about discussing about specific systems
> instead of 'general case'? Namely - Windows. They do not have
> symlinks, but they have those .LNK files which to some degree
> work as symlink, at least for GUI tools. Maybe it would make
> sense to convert symlinks to .LNKs?
I don't really know anything about .LNK files. From what little I've
tried to do with them, I don't think that they can help out with this
(when you open such a file in an editor, you get binary data, not the
file being linked to), but I would be happy to be proved wrong.
More information about the Mercurial-devel