On remote weaves

[John A Meinel]

Aaron Bentley wrote:
> 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.

I agree. I don't know if Weave is easier to use as an in-memory format.
But there should be a transformation from revfile to weave (and back)
which doesn't go through the full text.

>
>
...

>
> 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.

You can do anything over XML-RPC. :)

I think you have a reasonable point, that we might just talk to the
server in terms of changesets, since those can already represent
everything in a reasonably compact form. (Once changesets are merged
into mainline :)

>
>
>>>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.)
>

After reading the spec, sftp really just seems like a remote filesystem.
It has open/read/write/close/lock etc.

I feel that development should proceed on making SftpTransport fully
utilize the sftp protocol, since it gives us pretty much everything we
need for handling remote branches like they are local ones (no bzr
specific server).

>
>>>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.

I don't really like plain ftp either. Just thinking that some people
might have upload space, accessible over ftp, but not over sftp.
It isn't a priority for me, but if ftp has the same level of support
that sftp has, it seems it would be possible to make some people happy.

Anything using XML-RPC should be designed as a SmartServer, which deals
in much higher concepts possibly just plain changesets, possibly
something else.
I'm not sure if there should be a "bulk update" mode which is separate
(lets you download the exact revfile/weave rather than pulling the
changes one-by-one, I'm guessing for flat/compressed text stores,
computing the delta would be a sufficient bandwidth improvement to be
worth it).

The other part with the current serialized form of changesets, is that
they are meant to be human readable, not maximally packed for transfer
and machine understanding.
It could certainly be easier to pack up Python objects in a pickle, and
pass them across. I'm guessing that would be less cpu intensive than
parsing an ascii text file.

But thanks for the sftp draft, it showed me just how capably the
protocol is.

John
=:->


>
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050802/b7c5bd49/attachment.pgp