[RFC] proposed user doc for nested trees

[Aaron Bentley]

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

John Arbash Meinel wrote:
> 
> ...
> 
>> I don't understand what makes them more fragile.  We had a guarantee
>> that heads not referenced by the branches in a repository could safely
>> be garbage-collected.  Stacking breaks that guarantee.  I don't see how
>> it could be more broken.
> 
>> Even if shared branches were required, we still could not restore that
>> guarantee, because a historical revision of the containing tree might
>> refer to a revision of the subbranch that was not in the ancestry of the
>> subbranch's head.
> 
> But we *could* guarantee that when we fetch the historical revision of
> the containing tree, will will also fetch the referenced revision of all
> subbranches regardless of whether they are in the ancestry of any given
> branch.

I've already described a very similar guarantee in
http://bazaar-vcs.org/NestedTreesDesign#pull-and-non-initial-push

It doesn't address garbage-collection, though.

Both guarantees would fetch the revisions into the repository of the
subbranch, it's just that yours would require the repository of the
subbranch to be the same as the repository of the containing branch.

> I also prefer an 'everything is in this repository over here' approach.
> Whether that is just requiring you to be using a shared repository when
> using subtrees... I'm okay with that.

What would you think if our subtree repository format was always a
shared repository?  Upgrading to support nested trees would then
automatically make the repo shared.  For standalone trees, it's pretty
rare that it matters whether the repository is shared.

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

iEYEARECAAYFAkoNdy4ACgkQ0F+nu1YWqI2X8gCfVoexRVrlYdRYzbJ5nFF0iYIt
+RQAnRT3ZeYwCo3VzDLf6fyi9yQDliq8
=Gd5y
-----END PGP SIGNATURE-----