[darcs-devel] performance measurements of "darcs get", "hg clone", and "rsync -r"

[Pekka Pessi]

2008/1/26, David Roundy <droundy at darcs.net>:
> > Such a server mode would (1) sidestep the need for flaky control
> > master connections, (2) would eliminate the need to rely on scp and
> > sftp (and the need, on Windows, to set up the Putty semi-equivalents),
> > and (3) would perform and function equally well on Windows. And (4) it
> > should perform great.
>
> Yes, that would be nice.  It *would* add a requirement for darcs to be
> present on the server (not a huge requirement, and we could always fall
> back on scp).  And most folks who get and pull over ssh will also be
> pushing over ssh, which already requires darcs be present on the server.

> It also would require that we develop an entire ftp protocol including
> transmition of errors.  I think this would definitely be harder than
> learning haskell.  Which isn't to say it's not a reasonable problem to
> tackle, but rather that your lack of Haskell knowledge isn't an excuse!

Been there, tried to done both. Now I have working sftp and almost grok $.

My darcswrap.py includes sftp implementation in less than 800 lines of
Python, gruesomely butchered from innards of Twisted Conch.  See
<http://sofia-sip.org/~ppessi/darcswrap/>. I briefly considered
implementing the darcswrap in Haskell, but gave up due to
aforementioned reasons.

If using the sftp protocol you could say something like

ssh 'darcs --server-mode || /usr/libexec/openssh/sftp-server'

and cope with systems without darcs or with an older darcs version. In
latter case you simply had to invoke 'darcs apply' in separate ssh
connection.

The expired I-D draft-ietf-secsh-filexfer-13 describes sftp,
draft-ietf-secsh-filexfer-extensions-00 how to extend sftp (with
darcs-specific messages).

> One might also wonder why we don't use the existing sftp program, which
> itself implements quite a similar protocol to what you're proposing.  In
> fact, we do so, but haven't wanted to deal with the headache of maintaining
> the connection, so we only do so during darcs get (when we know in advance
> an entire list of files we'd like to grab).  And this itself turns out to
> be somewhat fragile, as not all sftp servers are identical (and of course,
> putty never names any of its commands in a standard manner).

SFTP clients you mean? Well, perhaps it easier to reimplement sftp
than try to control random sftp client in win32...

-- 
Pekka.Pessi mail at nokia.com