On remote weaves
mbp at sourcefrog.net
Tue Aug 2 20:56:14 BST 2005
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050802/4b90111b/attachment.pgp
More information about the bazaar