Mommy, where do subtree branches come from?

[Aaron Bentley]

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

So I'm working on nested subtrees, and I'm hoping we can go public with
them for 0.16.  But I haven't written in the final mechanism for finding
subtree branches.

The whole point of subtrees is that a subtree can come from a different
location than the containing tree.  So program "foo" can come from
foo.com, but the library "bar" can come from bar.net.

It seems to me that we want containing branches to store a mapping of
subtree file-ids, to branch locations.

Here's why:
1. subtree branch locations should vary by project.  "foo 1.0" may use
   "bar 1.0", while "foo 2.0" uses "bar 2.0".  Yet because "foo 2.0" is
   derived from "foo 1.0", they will use the same file ids.  If there's
   a global or repository-wide association of subtree ids to branch
   locations, then "foo 1.0" and "foo 2.0" will not be able to point to
   different "bar" branches.
2. subtree branch locations should vary by repository.  A repository for
   internal use may refer to internal-only branches, while a public
   repository of the same branches should refer only to public branches.
   This means that subtree branch locations should not be versioned
   values (e.g. in the inventory)
3. subtree branch locations should not be permanent.  The user may have
   no control over the locations of branches published by other people.
   If the branch moves, the new address should be used.  This applies
   even when retrieving old revisions.  This also means that subtree
   branches should not be versioned values.
4. subtree branch locations must be accessible from either branches or
   repositories, so that operations on the containing branch can also
   use data from subtree branches.  This rules out working trees.

But there's a problem, and it happens when subtrees have both their
branch and tree at the same location.

Say we have a layout like this:

tree/
tree/subtree/
tree/subtree/subsubtree/

We start with it as a non-nested tree at revision 1.

Then make subtree a by-reference tree, and we make subsubtree a
by-reference tree.  Then we commit, producing revision 2.

If we revert to revision 1, then these new branches, "subtree" and
"subsubtree" will be deleted.  If we revert back to revision 2 after
that, then we will not be able to reproduce the data that was formerly
in "subtree".  That means we won't know where to get "subsubtree" from.

Here are the two options I've come up with:
1. store backups of the branches in "tree" when reverting to revision 1.
   This seems messy.
2. store all the subtree location information in the containing branch
   as well.  Since file-ids are currently unique in nested trees, it
   should work.

Any thoughts?

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

iD8DBQFGDxml0F+nu1YWqI0RAp8zAJ9d5kchTDLE8IRFO6lexzoe9QRjLACfZegz
w3S9WoGkboZWzG5AQOVnQW8=
=47Pf
-----END PGP SIGNATURE-----