[RFC] proposed user doc for nested trees
John Arbash Meinel
john at arbash-meinel.com
Wed May 13 03:29:12 BST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ian Clatworthy wrote:
> Aaron Bentley wrote:
>> Aaron Bentley wrote:
>>> Since the code isn't updating any extra info, updating branch reference
>>> locations would be a big burden, and you'd need to ensure that it was
>>> impossible to move a checkout any other way, to avoid breaking the
>>> user's tree. That's a very difficult guarantee to provide.
>>> Whereas, moving checkouts around is a fairly rare event.
>> What I mean is that moving subtrees within a working tree would be much
>> more common than moving an entire set of nested trees (composite tree)
>> around.
>
> I disagree. I regularly do something like:
>
> bzr branch trunk foo
> (hmmm - bar is a better name for that branch)
> mv foo bar
>
> That needs to work if foo has nested trees. *I* think we want
> lightweight checkouts to use relative paths just like Alexander
> suggests, for this case and many others.
>
>> I think that means we should optimize for the first one, but it doesn't
>> mean we can't support the second. For example, perhaps "bzr switch" in
>> the root tree could update the branch references.
>
> Using "bzr switch" like this is a workaround. It isn't "Just Works" IMHO.
>
> Ian C.
>
>
I think there is a point where it is also common to do:
mv libfoo libfoo1
However, the relative path in that case continues to work, until you
rename it to a different depth.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoKMHgACgkQJdeBCYSNAAMfQQCeL5gOAFSYBTUxB0TRCaBSItLV
z8wAoMNN4N2vFZ3YXoX/y11h1BaQywlA
=avA2
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list