adding [minimal] symlink support

[Giorgos Keramidas]

On 2006-07-11 17:56, Matt Mackall <mpm at selenic.com> wrote:
>On Sat, Jul 08, 2006 at 08:58:41PM -0700, Bryan O'Sullivan wrote:
>>On Sat, 2006-07-08 at 09:40 -0500, TK Soh wrote:
>>> This may be the last time I bring up on this topic again, so please
>>> bear with me.
>>
>> No problem.  I think that handling symlinks would require several days
>> of work.  It's really not technically difficult, just fiddly.
>>
>> Matt is busy redoing the merge code at the moment, so this would
>> presumably be the right time to add symlink support.
>
> I don't think I've got time to delve into coding this right now,
> actually. But I'll share some thoughts on adding "basic" support:
>
> manifest.py has a concept of flags. Currently, we only have one flag
> bit, namely execute. This is represented by adding an "x" to the end
> of the file hash in the manifest. Symlinks should have an "s" instead.
> A file can't have both.

Why are these flags exclusive?  Some systems support changing the file
flags of the symlink itself, with Python's os.lchown() and os.lchmod().
I'm not sure what effect these have on systems where symlink support
doesn't really support lchmod() semantics.

> Probably the best thing to do here is to simply take everything after
> the hash and put it in the flags hash (see manifest.read()). This
> takes a minimum of parsing.
>
> Then change all current users of flags to do 'if "x" in flags[f]'
> instead of 'if flags[f]', etc.
>
> Then, symlink support is done by using the "s" flag appropriately.
> We'll store the link as the "content" of the file for commit.
> [...]
> I've pasted this to
> http://www.selenic.com/mercurial/wiki/index.cgi/SymlinkPlan

This, on the other hand, sounds much better :-)