Re: [Monotone-devel] Packets or Packet I/O no longer works?

[Will Robertson]

(see below)

On Wed, 2005-05-04 at 10:39 -0700, Nathaniel Smith wrote:
> On Tue, May 03, 2005 at 04:58:47PM +0100, Will Robertson wrote:
> > Thanks, Clemens,

[...]

> > afraid having to rely on full network access for sync'ing multiple
> > repositories is a bit of a show-stopper for me.
> 
> Hmm, so all you want is the ability to say "take that revision and
> that revision and that revision, and put them in a file"?  Yeah, that
> should be quite straightforward to script up.  (Basically, for each

[...]

OK, I'll have a go at it.  I couldn't find any docs on how each of the
rdata/mdelta/etc commands related to each other, so my
less-than-competent attempts just made me more confused.  The "old
behaviour" allowed me to ask monotone to just export all revision data
and history since such-and-such a revision/time, which could be applied
against a different repository, and that one would simply ignore any
data it already had.  This is what I do with darcs at the mo'.

> >   Even Git seems promising in this regard, in-as-much as it's just a
> > bunch of files, and rsync is just a file-transfer mechanism.
> 
> A monotone database is also just-a-file, and if you really want to
> rsync it (dunno why you would, it doesn't take any less network
> connectivity than netsync, and is less efficient), I bet it works

Assuming you use rsync across the network.  It's quite good at keeping
multiple local directories in sync (e.g a removable usb-key).

It's nice that git works at a file-system level, which means you can
take advantage of all the file-system tools out there without much
effort.

> better than rsync'ing git repos :-).  (Because monotone's db stores
> deltas, whereas currently in git, you have to transfer complete copies
> of every changed file.)

Yes, I've read a big debate on git vs. Mercurial, where Mercurial is
essentially git using file-deltas and file-history instead of just
collections of files and change-set history.

One of Mercurial's author's big arguments is that even if "disk is
cheap", bandwidth isn't, and rsync'ing a large repository is likely to
hurt at both the client's and the server's end.

-- 
Will.