[RFC] Treating symlinks as their targets

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> I had an interesting discussion on IRC with gwilma. They had a request
> to version symlinks not as symlinks but as the target contents.
> Specifically, he wanted to do something like version $HOME, and wanted
> to make sure that both the local files, and the remote files got versioned.

Let me just point out that this is generally bad behaviour for a VCS.
People expect a VCS to version a subtree, and not to affect anything
outside that subtree.  It would be easy to write an exploit that used
this facility to alter ~/bin, for example.

> From an implementation perspective, it seems like we could hack in and
> just change to using 'os.stat()' instead of 'os.lstat()'.

Versioning symlinks as their contents leads to aliasing issues.  That
is, a given file's contents could be versioned once as a plain file, and
again as a symlink target.  It wouldn't surprise me if this user's $HOME
had at least one symlink pointing to another location inside $HOME.

So I would defer treating symlinks as their contents as long as
possible.  Commit and add should definitely be aware that they're
handling symlinks, not files or directories.

> I think 'pull' and 'merge' might fail, because they use
> .bzr/checkout/limbo for temporary files, and rename them into place
> (which would fail across mount points).

Correct.

> To fix that, it would be possible to create temp files in the directory
> they will end up. (Which might have a performance implication, because
> of other discussions about inodes, etc). I don't think TreeTransform
> supports it as is.
> Aaron, any ideas as to what it would take to change TreeTransform to try
> and use target directories instead of a limbo directory? 

A subclass of TreeTransform could achieve this by reimplementing
limbo_name, I believe.  (I'd have to see significant performance
enhancement to justify doing it as our standard behaviour.  There's just
so much room for error.)

> I realize some
> things get really complex, because the target dir may not exist yet if
> someone is adding a whole subtree.

True, and further, you have to account for the possibility of a file
being moved into a different parent directory before the transform is
applied.

> I don't think this would be a real core feature, but it might be a
> useful plugin.

I think it would be hard to implement this a plugin.  In order for 'bzr
checkout' to behave properly, it would need to store both symlink target
and target contents, so it would require a new repository format.  It
would require sticking a new TreeTransform into existing
merge/pull/revert functionality.  And I'd definitely want a switch to
enable this behaviour.  Such a switch would need to apply to 'bzr
branch', 'bzr checkout', 'bzr push', 'bzr init', and possibly others.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFE6fMG0F+nu1YWqI0RAuCrAJ9nIQrXZg74KCqmVKgqHXgfiUUJ8gCfZFFd
PWb/eXI5K+roNTmlJbqEEsI=
=UQKD
-----END PGP SIGNATURE-----