[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