monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Packet I/O howto


From: Jeronimo Pellegrini
Subject: Re: [Monotone-devel] Packet I/O howto
Date: Sat, 22 Apr 2006 07:27:26 -0300
User-agent: Mutt/1.5.11+cvs20060403

On Fri, Apr 21, 2006 at 09:46:53PM -0700, Nathaniel Smith wrote:
> On Fri, Apr 21, 2006 at 11:01:56PM -0300, Jeronimo Pellegrini wrote:
> > I have been playing with packet I/O, and found that the documentation
> > gives commands for packet transfering, it doesn't say what exactly (and
> > in what order) I should do to transfer revisions between databases. I
> > found out, and thought I'd write this mini-howto for Monotone 0.26. I
> > hope it's useful.
> 
> Thanks!  Would you be interested in adapting this to go in the manual?

Yes, sure. But where in the manual would it go? (I already have the
sources that I sometimes pull from net.venge.monotone)

> > mtn automate packets_for_revision ID
> 
> Seems useful.  Should it include certs or not?  (For mtn-dumb's use,
> it should not, because mtn-dumb wants to get certs separately.  But it
> would definitely make the get-files-and-revision stuff simpler.)

I think it would be OK to run:

$ mtn automate packets_for_revision ID
$ mtn automate packets_for_certs ID

The problem is when you need to go finding all fdatas and fdeltas... If
the changeset is too large, it may take some time (or you may have to
write a parser for the output of get_revisions just for that).

> > $ mtn -d A automate graph|awk '{print $1;}'|xargs -- mtn -d A automate 
> > toposort
> 
> $ mtn -d A automate select i: | mtn -d A automate toposort address@hidden
> 
> (Simpler, plus more reliable -- if there are enough revisions, xargs
> may decide to run its command multiple times (because of OS command
> line length limits), which would give incorrect results in the case of
> toposort; the brain-onna-stick switch has no such limits.)

Thanks a lot! I hadn't thought that I cold have this problem with xargs.

J.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]