Traversing symlinks

Dominik Psenner dpsenner at gmail.com
Fri May 20 06:17:49 CDT 2011



> -----Original Message-----
> From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
> bounces at selenic.com] On Behalf Of Joel B. Mohler
> Sent: Friday, May 20, 2011 12:45 PM
> To: mercurial-devel at selenic.com
> Subject: Re: Traversing symlinks
> 
> On Friday, May 20, 2011 06:00:35 am Dominik Psenner wrote:
> > >
> > >
> > > Maybe someone wants to make a deep path shorter by making a symlink.
> The
> > > symlink may or may not be tracked, the point was just that Mercurial
> > > behaves in an atypical way here compared to other Unix tools.
> >
> > hm I was more thinking of something like:
> >
> > $ hg init
> > $ ln -s /etc
> > $ hg add *
> > $ hg commit
> >
> > At this point, I would expect mercurial to track the history of the data
> > stored at the symlink location as if that data was physically there.
> 
> So this seems useful (in a gross kind of way) to version your /etc folder,
> but
> what happens when you clone and update this on another computer?  I would
> certainly hope it wouldn't overwrite your /etc.  What would you want to
> happen?

A symlink is mostly something system-dependent and thus can't be replicated
easily across different systems. As stated before, mercurial should not
track a symlink at all as that yields to lots of other problems.

Mercurial should IMHO treat the etc symlink as any other file or directory
inode by dereferencing it. Cloning this repository would therefore not
produce a symlink to /etc, but an entire etc folder within the working dir.

One could for example track the overall configuration of a productive
website server environment by creating one repository and doing this:

$ hg init
$ ln -s /etc
$ ln -s /var/www
$ hg commit

One could replicate the productive environment by doing something like:

# get the data
$ hg clone
# set up the system and re-enable mercurial to track etc
$ mv /etc /.etc
$ mv etc /etc
$ ln -s /etc
$ mv /var/www /var/.www
$ mv www /var/www
$ ln -s /var/www

And stay up to date to the other productive environment by doing:

$ hg pull --update
$ reboot

Obviously all these things must be done by hand and should never be done by
mercurial. :-) IMHO this is a real world use-case for "versioned" symlinks.

> 
> What about when someone else changes this repository and you re-update on
> your
> side?  I guess it will honor the symlink and update in your /etc.  I hope
> you
> never do an "hg purge".  All-in-all it seems rather opaque and scary to
> me.
> 
> I'm not sure why you would do this instead of versioning your /etc
> directory
> directly (which I already do).  I guess I'd better not do an 'hg purge'
> either, but all that seems much more obvious in a non-symlinked context.
> Note
> that I'm rather selective about what I include in this repository and my
> /etc
> almost certainly includes symlinks whose ambient directories I've not been
> motivated to version yet.
> 
> Joel
> 
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list