Not following symlinks causes weird bugs
John Arbash Meinel
john at arbash-meinel.com
Fri Mar 9 20:33:20 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> So basically, on the 'users' directories, they have a symlink over to
>>> the main repository.
>
>>> For now, I've changed their setup to use a BranchReference rather than
>>> using a real symlink. But this was certainly the source of a lot of
>>> confusion (for me, and for them).
>
> Yeesh. As you well know, bound branches are usually a good match here.
> One of the abstraction leaks of our heavyweight-checkout /
> lightweight-checkout model is that bound branches are useful by themselves.
>
> I wonder whether we should mention that more often?
Well, what they actually wanted was a BranchReference. And we don't have
a good way to create one of those right now. (bzr checkout
- --lightweight, rm -rf .bzr/checkout ; assuming '*' doesn't match .bzr).
checkout --lightweight, and remove-tree would work, except remove-tree
explicitly doesn't work on lightweight checkouts.
So instead I just recommended that he not use symlinks, and just educate
users to get things from the right location.
There specific need is that 'mainline' had different permissions. Which
is a reasonable use case.
>
>>> The best I can come up with, is that once BzrDir finds out that there
>>> *is* a bzrdir at a location, it should then change the transport over to
>>> a realpath() version of it. And then continue to search for things like
>>> repositories from the realpath version.
>
> I think that makes sense, but it won't solve the problem on every
> transport. Symlinks are often indistinguishable from normal files.
> Perhaps repositories should have a UUID, maybe tied to inode?
>
> Aaron
Well, that only really helps if branches know what repositories they are
in. And there have been reasons not to do that, though I wonder if it
isn't worth the tradeoff.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF8cSQJdeBCYSNAAMRApKnAKDMF49fwX9e1jAfKgjGksE9MCiDsQCdFe65
lldC+Prm1vv1VmyynK4LEOI=
=jd8Y
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list