[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Packets or Packet I/O no longer works?
From: |
Will Robertson |
Subject: |
Re: [Monotone-devel] Packets or Packet I/O no longer works? |
Date: |
Thu, 05 May 2005 12:13:35 +0000 |
(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.