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

[Nathaniel Smith]

On Thu, May 05, 2005 at 12:13:35PM +0000, Will Robertson wrote:
> (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'.

Nod.  What is also useful might be to add some automation to say
"everything since last time I ran this".  You can do this by taking
the output of "monotone automate leaves" and saving it to a file
after you run your script; then, when you want to find what's new
since that time, you run "automate leaves" again, and for each
revision it outputs, run "automate ancestry_difference <a new leaf>
<all of the old leaves>", combine the output of all these commands
into a list, remove duplicates, and run the above-described export
script on each.  (See the ciabot script in contrib/ for an example of
this technique.)

What this will miss is if you create certs on existing revisions,
e.g., if you tag one.  For that you'll just have to do something by
hand...

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

Well, you can use rsync to make two local monotone databases the same
as well :-).  (Though, again, netsync might be somewhat safer.)

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

Well, he's right :-).

(If you have some intelligence on the server, of course, you can do
better than rsync on bandwidth usage, and still store whatever you
want on disk.)

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."