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.
While this solution would be solving minor problems, it would also be a
rather small change. I still haven't had time to learn haskell, but I'd bet
that with the avalable libs this could be done in just a few lines of code.
The moderate benefit:
* Darcs would be capable of operating over a single
connection, for any future situation where that
was beneficial.
The minor benefits:
* A chroot jail would only need a basic shell and darcs
(and lib dependancies) in order to receive patches.
(i.e. no scp)
* There would only be a single ssh connection for
people who haven't set up ssh-agent.
* Fewer temp files required (straight to RAM instead
of scp-ing a file)
The minor disadvantages:
* Another option, and more code.
The moderate disadvantage:
* New versions of darcs would have to try pushing this
way, and fall back to scp if the receiver is an old
version.
Thoughts?
-Mike
|
