On remote weaves

[Martin Pool]

On  2 Aug 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

> I think this adds an unnecessary requirement, since all of the data in a
> weave can also be produced from flat stores.
> 
> 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.  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.

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

> > The other possibility was to make a SmartBranch, which started to
> > override more of the Branch operations. Aaron was thinking that it could
> > serve up the .text_store and .inventory_store, etc on it's own (not a
> > separate Storage + Transport class). He feels that they are part of the
> > public interface of Branch, and thus needs to be preserved.
> 
> The reason I say they're part of the public interface is because their
> names don't begin with '_'.  That makes them public variables, and part
> of the interface.

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

> I don't see what's lacking in the sftp protocol.  Locking and pipelining
> are both explicitly supported, as well as lstat.  It's just that by
> using the commandline sftp client you limit yourself to what it
> supports, and you aren't able to take full advantage of the protocol.
> 
> I can understand that it would be fun to implement your own remote
> filesystem protocol, but unless there are capabilities SFTP lacks, I
> think it makes more sense to use what's already out there.

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050802/4b90111b/attachment.pgp