Symlinks support status?

[Dov Feldstern]

Douglas Philips wrote:
> <delurk>
> On 2007 Nov 4, at 3:48 PM, Dov Feldstern 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.
> 
> Ugh. Having read your original message again, I think the problem is  
> with a build environment based on symlinks being ported to a platform  
> where they aren't available.
> 

Well, yes, that's exactly the issue we're dealing with: mapping a 
symlink-capable tree to a non-symlink-capable one. Except that the way I 
see it, the symlink capable tree is the hg (or ClearCase) repository, 
and the non-symlink-capable one is the working directory on, e.g., 
Windows. The current mapping in mercurial is incomplete, in that it does 
not allow the normal tools to really work with the working directory. My 
suggestion would alleviate (though not solve all edge cases, e.g., 
symlink cycles) this problem.

> I do not think this is a "problem" with hg (or git or darcs or  
> subversion or ...).

I don't think I ever claimed that this was a "problem" with mercurial 
(until just above, but you used the term "problem" first ;) ). 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).

> 
>> (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.
> 
> In other words a version control system with-in a version control  
> system. Ugh^2.
> 

It remains to be seen whether or not this really adds that much 
complexity. If not --- and I suspect it needn't, at least not for the 
"first stage" I mention above --- I'd say it's only Ugh^1.032...

> Sorry, Dov, but I think you are asking a version control system to  
> solve an operating system problem (file system symlink support).  It  
> seems akin to asking why a VCS doesn't convert JPGs to Windows BMPs,  
> shell scripts to .BAT files, etc.
> 

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).

> Having worked at a company where we built products on multiple  
> platforms, symlinks were not the right solution for our build  
> infrastructure. Multiplatform builds can be done, and cleanly,  
> without symlinks, as can builds using components provided by other  
> parties. Fixing hg (or/git/darcs/etc.) because someone is stuck with  
> a platform-dependent build process seems wrong.

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...

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...

> 
> 	--Doug
> </delurk>
> 

Thanks for your comments!
Dov