[darcs-users] reimplementing darcs put

Guillaume Hoffmann guillaumh at gmail.com
Tue Jun 8 09:06:42 UTC 2010


Hi everyone,

this darcs init x problem made me have a look at darcs put, and the
criticisms it received in the past (mostly: slowness and lack of
progress report, see darcs-users archives of December 2008, eg
http://lists.osuosl.org/pipermail/darcs-users/2008-December/016452.html
).

Using init+push rather than get is inefficient because with get, the
pristine tree is copied once for all, while with init+push it is built
on-the-fly for each patch, is that right?

Implementing put with get for local copies is easy, but via ssh (the
typical use of put), that's a problem.
A solution, explained by Petr at
http://www.mail-archive.com/darcs-users@darcs.net/msg11858.html ,
would be:

ssh -R 2000:localhost:22 somewhere.else
SSH_PORT=2000 darcs get localhost:some/repo

But this requires the user to have a ssh server on their local
machine, and ssh would prompt the password and maybe use the wrong
username to connect back to the local machine.

So, to remain simple, the put command via ssh has to be forward-only.
Two options I see:

1) scp-ing a tarball of the local _darcs, untarring it and
darcs-getting it. (darcs-reverting it would work but would leave all
_darcs/prefs/ files like mots, email...).
Seems dirty, but this is what put does: deploying a repository on a
remote server.

2) adding a hidden "--put" flag to darcs push, and passing this flag
to the call of darcs push by darcs put. --put would imply -a and
disable pristine construction except for the last patch ? Then go as
before, init+push. The implementation of the put command would remain
compositional (=reusing other parts of darcs' code), thus less
error-prone, I guess.

I have the following assumptions on these solutions:

Option 2) would be only a slight improvement of the current situation
since we would still copy patches one by one, and also its
implementation seems harder than 1).
Option 1) requires a temporary directory on the remote machine to
uncompress the tarball, this is maybe a downside.

I'm more in favor of Option 1), especially since there is currently
work by Alexey on darcs optimize --http. Maybe we could use the same
code for darcs-getting the contents of a tarball?
Once we can write the following, the rest will flow:

$ darcs get repo_name.tar.bz2 # contains only the _darcs directory

Are we risking feature creep with that ?
What do you think?

guillaume


More information about the darcs-users mailing list