On remote weaves

[Aaron Bentley]

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

John A Meinel wrote:
>>Since we don't need a lot of weave data for a merge, just the history
>>since any last common ancestor, I'm not convinced that we need local
>>weave storage at all-- we can just generate them at need, and the cost
>>is proportional to the number of commits to that file since the last merge.
>>
> 
> 
> I would prefer not to see weave storage, since I don't like storage
> mechanisms which modify in place.

Personally, I think I like revfiles better than weaves, because they're
append-only and don't require the whole file to be read.  Seems like a
reasonable way to compress.

>>The problem with that is commands like update_revisions, which operate
>>on another branch's *store members.

> Except that is done *within* branch. Generally, when a class has private
> members, another object of the same class can access them, because it
> should know what is going on, and how to maintain consistency.

Yes, but these aren't the same class, they're related classes.  And if
Branch.update_revisions() uses the underlying storage anyhow, how's it
supposed to work with a SmartBranch?

> It is different for one Branch to access another Branch's private
> variables, versus having a Command do so.

Yeah, I'm still used to RemoteBranch being a separate object type.

> It is, but that doesn't make an optimal communication protocol. For
> instance, when requesting an object, it would frequently be good to
> alert them to what objects you already know about, so that it can send
> smaller chunks.
> 
> For instance, I could tell the server that I need the inventory for
> revision X, but I have the inventory for it's parent. The server could
> then just send a diff of X versus it's parent, rather than sending the
> full text. For large inventories, this would probably be quite a bit of
> bandwidth savings.

First, I don't understand this example.  Surely you'd grab the whole
revision while you had the chance, so you'd get the server to send you a
changeset, not diffs.

Second, I don't see why you can't do what you're talking about over
XML-RPC.  All you'd have to do would be to define a
get_inventory_text_diff() method in the SmartServer.  That would then be
automatically available to be called.

> I have no problem with a more advanced use of the SFTP protocol. I
> haven't ever really seen anywhere where it was fully defined.

The spec is here:
http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/draft-ietf-secsh-filexfer-09.txt

(yes, it has append.)

> I suppose some would like regular ftp support, but I don't know if the
> ftp protocol supports everything that we would need.

The 'plain passwords' thing is always the dealbreaker for me.  I'd want
to safely restrict write access.  For read access, no reason we
couldn't.  In fact, it would be pretty simple to make the mainline
RemoteBranch use geturl for ftp branches.

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

iD8DBQFC764P0F+nu1YWqI0RAmWVAJ97jOD9jX8VJ00KFiREmagqjshgtQCfcqzz
DfYLYjy23gG0YUxVGVl1z64=
=2UZ7
-----END PGP SIGNATURE-----