On remote weaves

[Aaron Bentley]

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

Martin Pool wrote:
>>So one approach is to copy all the relevent revisions from the remote
>>branch to the local branch, and then do the weave using local data.  So
>>you don't have to worry about the RemoteStore interface-- only
>>Branch.update_revisions needs to.  And you don't need to convert data,
>>because we'll assume your local storage is already a weave.
> 
> 
> We'd like to make downloads faster too.  If the storage is compressed
> (as a weave or revfile or whatever) then an obvious way to do faster
> downloads is to send the compressed form to a client that wants it.

My impression was that weaves were not very compression-friendly,
because the data required for a particular revision might be scattered
all over the weave, and there was no master index of line locations.

When updating, you only need changed lines, and those will tend to be at
the end, but still, finding them would be hard.  If I'm wrong, that's
great.  In any case, it doesn't seem fundamental to the weave concept,
so it can be fixed.

BTW, tridge's description of SCCS weaves on #revctrl recently was quite
interesting.  One thing he mentioned was 'excludes'-- I'd been wondering
how to handle updates with diverged trees in a weave.  Storing excludes
in the weave itself seems like a layering problem, though.

> For
> a client doing an initial checkout, they can get the weaves and put them
> into their local directory.  For a client doing an update, they have a
> few options: get the weave and merge it into their local files; get each
> of the revisions one by one; or get deltas between particular revisions.

This sounds like smart server territory, so I'll advocate that clients
doing an update should request changesets from the server.

> I'm not totally convinced either, but I feel like I've stalled on it for
> long enough and we should go forward and see what happens.

Okay, fair enough.

>>The reason I say they're part of the public interface is because their
>>names don't begin with '_'.

> I think it's a bug that they're public.

Cool.

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

iD8DBQFC79dk0F+nu1YWqI0RAqIZAJ0dohJfYuDQ7pAXjsoz6ACEf6LQNwCfdhDm
rfn7Zf1G72gVR+90p6rztws=
=nAUn
-----END PGP SIGNATURE-----