[darcs-users] push --and-apply

[David Roundy]

On Tue, Sep 16, 2003 at 05:21:57AM +0300, Aggelos Economopoulos wrote:
> I'm trying to find a way to easily exchange patches between repositories
> in my home machine (which doesn't have a permanent connection to the
> outside world) and repositories in an always-up remote host.
> 
> At first, I was thinking about using http and the ssh port redirection
> feature for doing remote->local pulls (remote->local means the 'darcs
> pull' command runs on local) and darcs push -o ...; scp ...; for
> local->remote patch transfers. That was until I went through External.lhs
> and stumbled on read_ssh - it should definately be more widely
> advertised; it's only mentioned in the "Building darcs" section in the
> manual and in a month old thread in darcs-users (I'ld submit a
> documentation patch but I haven't been able to make it work yet - see
> below).

The reason it's underdocumented is that I've never used it.  It was
submitted by Peter Strand.  The solution I use to this problem is the email
push solution.  The ssh one is definitely more elegant, at least if you
don't want to run the test.  I do want to run the test (which takes a few
minutes), and so I like the push to be asynchronous.

> Trying to do a pull from a repository I've copied in rhost:/rpath/ results
> in the following error message (actual paths removed):
> 
> aggelos at erwin:~/4tmp/> darcs pull username at rhost:/rpath/
> Error in subprocess: Virtual timer expired
> 
> Fail: user error
> Reason: (scp2) failed to fetch: username at rhost:/rpath//_darcs/inventory

...

> Any clues?

Yuck.  I also ran into this problem when testing the curl (as opposed to
libcurl) version.  I don't properly understand it, and so I came up with a
very crude hack for copyRemoteCmd, which was to retry every time I failed
due to a SIGVTALARM interrupt.  This worked because the error was only
sporadic.  It may also be sporadic in the scp case, I just don't know.

As I understand it (and I don't very well), the virtual timer is an
interrupt timer that gets called when a certain amount of CPU time is used
by a process.  When it is called, the process dies, and that is what is
happening.  What I don't know is why the timer is getting set in the first
place.  My only guess is that for some reason execvp is setting the timer.
Either that or it is getting set when I fork.

The proper solution would presumabley be to either reset the timer using
setitimer or to set the forked process to ignore the SIGVTALARM signal
(using signal(2)), but I hesitate to implement such a solution when I don't
understand the problem.  On the other hand, perhaps one ugly kludge is as
bad as another...

As a first try, you can copy the code from copyRemoteCmd which just retries
when it gets a SIGVTALARM failure.
-- 
David Roundy
http://www.abridgegame.org