[Fwd: 'forest' extension]

[John Arbash Meinel]

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

Wouter van Heyst wrote:
> On Mon, Jul 17, 2006 at 11:03:08PM +1000, Robert Collins wrote:

...
>>>> Personally, I'd love to see Aarons work to add root ids finely reviewed
>>>> and merged, so that that we can implement nested trees by reference,
>>>> which I am still convinced is a much nicer way to do it.
>>> I thought you were vetoing this until we had a repository format that
>>> contained VersionedFiles for root ids?
>> My view on whats need to bring it in safely hasn't changed. I'm keen for
>> it to come in is all.
> 
> What needs to be done to get this moving, other than a format bump that
> is blocked by 0.9?
> 
> Wouter van Heyst

The format bump is required to properly version the root directory. (So
it can be changed, etc).
After we have that, we need to figure out the UI for supporting all of
it. And how to include the proper data into the inventory.

Stuff like:

1) how do we store locations where you can find the nested tree? (So
that people grabbing my branch over http, can get it, even though I use
sftp)

2) Command line arguments to enable/disable recursing into nested/parent
trees for stuff like commit, status, diff, etc. And determining what the
best default is. Similarly, we probably want to allow disabling
downloading of nested trees.

3) Teaching smart_add how to properly 'add' a nested tree.

4) ...

There are still a few hurdles, I think most of them are documented in
the spec. Our biggest problem is that because bzr is distributed, how
you get a revision and how I get a revision can be very different. We
don't really have a namespace/registry. Arch used a namespace, and you
could register locations for a given namespace portion. SVN has UUIDs
per repositories, so I assume you do a similar registration of locations.

I think we would like to support:

I'm grabbing your nested branch, but I actually already have a copy of
this nested child over here, can you grab it, rather than getting it
over the slow link?

In a first run, we might just leverage repositories (nested children
must be in the same repo as their parent). Or possibly, nested children
must have a public location which is a relative path away from their parent.

But long-term, we would like to do better. The data is there, but
figuring out how to make it nice needs a little bit of work.

John
=:->

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

iD8DBQFEu7/UJdeBCYSNAAMRAvAGAKDSnZs/wdAoto2/OAU9kUhSFy8LXgCeNKcr
m23MvuRze158NdZ5cA0Z/H8=
=1kKO
-----END PGP SIGNATURE-----