[darcs-users] Regarding darcs push and scp

[David Roundy]

On Mon, Nov 29, 2004 at 09:33:12PM -0500, Michael Conrad wrote:
> I originally started this email with a usage story, but in light of the
> traffic on this list, I'll get straight to the point.
> 
> I'm mainly looking for whether this idea would or would not work. (and
> whether its worth the effort)
> 
> What if "darcs apply" had an internally-used "--piped" flag with the
> following behavior:
>
> 'darcs push' would open an ssh connection and run 'darcs apply --piped'.
> the remote instance would then output the context of the repo on standard
> out.  It would then wait and listen on standard in to receive a list of
> patch names.  The local copy would generate a list of any additional patches
> it wanted to look at, and send the list.  The remote copy would then send
> all those patches and then wait for a response patch on stdin.  The local
> darcs would build a patch like normal and then send it through the
> connection.  The remote copy of darcs would receive the patch, and then
> continue execution as if it had read it from a file.

(Note that the existing code already pipes the patch bundle through ssh,
the scp business is in reading the remote repository, not in sending to
it.)

This is a good idea, although I think if we were to implement this much I'd
lean towards going the whole way, and implementing a darcs-ssh protocol for
reading darcs repositories.  Reading just the context isn't enough if we
don't share that context (e.g. if you're pushing to a repository that has a
tag that you don't have in your local repository).

The biggest trouble is technical, in a realm where my knowledge is
distinctly lacking.  Piping to and from external programs is a pain, and
the solution I've gone with in darcs is to just always write the input and
output of external programs to and from files.  Obviously, this won't work
with an interactive protocol.

So we'd need a new interactive pipe command.  I worked on this quite a
while a year or so ago, and had all sorts of "interesting" problems related
to buffers filling up and whatnot.  It may be that the new System.Process
module in ghc 6.4 will help here.  I haven't tried it out, although I did
look at it a bit.  If it really works (and really works on multiple
platforms), we could phase in using it on new darcs versions.  I'd *love*
to get rid of the hideous code in Exec.lhs (and its related code in
compat.c).
-- 
David Roundy
http://www.darcs.net