[RFC] proposed user doc for nested trees

[Aaron Bentley]

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

Vincent Ladeuil wrote:
>>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:
>     aaron> I'm not necessarily against using the repository of
>     aaron> the containing tree.
> 
>     aaron> Did you mean that if the containing tree's repository
>     aaron> was standalone, we would automatically convert it to
>     aaron> shared?
> 
> At least with the local branches.

Repositories are shared or unshared.  There's no option for them to be
partially shared.

>     aaron> Or did you mean that we would create a new branch type
>     aaron> that can use a standalone repository as if it's a
>     aaron> shared repository?
> 
> More or less.
> 
> I don't feel safe allowing any kind of branch (repository really)
> for the local branches.

You mean that you will only feel safe if a specific kind of branch and
repository are required?  ("I don't feel safe allowing any kind of
branch" usually means "I will only feel safe if there are no branches")

> If the containing tree's repository references revisions in other
> repositories, I feel that we are making the overall layout more
> fragile (more than the stacked branches case) and I don't see a
> clear way to guard against that.

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.

> That's why I thought you addressed that by using a shared
> repository between containing tree and local branches.

Sorry if I was misleading, but I said that if the containing branch's
repository was shared, it would be good to be able to take advantage of
that.  I also suggested that a subbranch might in some cases be a branch
reference (as used by lightweight checkouts).

> If that's not the case, I think
> http://bazaar-vcs.org/NestedTreesDesign#sub-branches should still
> be clarified by using more positive definitions.

I have reorganized it to put the declarations first and the rationale
afterward.  Does that help?

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

iEYEARECAAYFAkoNcFkACgkQ0F+nu1YWqI0PzACdHOHZkkZWRYy9lUffcGd+JTru
zXgAn1YmMhI3eozBo4L2q+plbetRWYou
=Gpn7
-----END PGP SIGNATURE-----