What might be handy for darcs push on remote servers where darcs is not
installed in the expected places, for example,
  darcs push --remotedarcs="/opt/local/bin/darcs"

Files affected: RemoteApply.lhs, DarcsFlags.lhs and DarcsArguments.lhs
I think.

This sounds reasonable.
-- 
David Roundy

Note that I when I made this request, I had not realised you could use edit your
.bash_profile or .cshrc on the remote end and it would find the right darcs. 
Not sure if --remotedarcs is all that useful then...

Not needed.  See http://thread.gmane.org/gmane.comp.version-control.darcs.user/10991

This just came up again in issue1025.  Since there is a decent workaround for
this, I'm leaving it as wont-fix, to avoid flag proliferation.

That said, it may be worth considering.  Maybe this sort of flexibility would be
useful anyway (do we want to make it convenient for people to "try out" other
darcses on the server?), and besides, we now have a notion of advanced flags to
mitigate the ill effects of flag explosion.

Somebody should just submit a patch and see what David thinks :-)

As suggested in issue1025, an alternative solution would be to have a
'local_darcs' preference in the remote repository telling anyone interacting
with that repo how to call darcs on this machine.

This way, if on my machine I have darcs installed in /some/funky/path/darcs-sfx,
I can just set local_darcs to that path. Anyone pushing to my repository will
execute this command.

If flag proliferation is a problem, instead of a flag, include it in the url
scheme, like so: 'darcs push toto@machine:/repo#darcs-command'. This way, it can
be saved in the repos file, and persist between session.

We should really go ahead and fix this after all.  Even if there are ways to
tell the remote end what darcs to run, they're too tricky.  Far simpler to just
let the client side control this.

I have a patch that adds --remote-cmd
the Ssh.hs file still needs patching to handle the transfer-mode. But I need the DarcsFlag for that.
Question is on how to pass it to Ssh.hs cleanly...

While the implementation of --remote-darcs is easy, it turns out that passing 
the network-related flags (in this case, RemoteDarcs), to all SSH-related 
commands affects _a lot of_ files.
Halfway through I stopped at Darcs/Repository/HashedIO.readroot, which may 
invoke SSH via speculateFileUsingCache => copyFileUsingCache => copyFileOrUrl => 
copySSH. As readroot is used to implement the class instance ReadableDirectory, 
I cannot think of an easy way to pass the network options at this point. Of 
course it would be possible to not supply the RemoteDarcs flag in HashedIO, but 
this seems rather inconsistent. Any suggestions ?

On Tue, Nov 17, 2009 at 21:55:38 +0000, Benedikt Huber wrote:
> While the implementation of --remote-darcs is easy, it turns out that passing 
> the network-related flags (in this case, RemoteDarcs), to all SSH-related 
> commands affects _a lot of_ files.

I was secretly hoping you'd work on this.

There are only two reasons that Darcs would invoke darcs on the remote
end:

1. for darcs push (ssh server darcs apply)
2. for darcs transfer-mode (to speed up fetching files)

It sounds like we could live with just getting (1) to work now and
(2) to work later...

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

I suggest to close this ticket, as the --remote-darcs flag is available
in 2.4 (see 'resolve issue223, add --remote-darcs flag for remote darcs
executable'). Another bug should be opened as the flag is ignored for
darcs transfer mode. As mentioned before, this is much harder to fix,
and affects a lot of code.

Closing this bug, as a --remote-darcs flag is available in darcs 2.4. See 
Bug #1736 for transfer-mode support.

The following patch updated the status of issue223 to be resolved:

* resolve issue223, add --remote-darcs flag for remote darcs executable 
Ignore-this: adb6bdc8ae27f98c63b8a39ba8eb750
This patch adds a flag '--remote-darcs COMMAND' to specify the name of the darcs
executable on the remote end. Unfortunately it currently only works for remote apply,
not for the transfer mode optimization. The problem: SSH transfers are used at many
points in darcs (eg, HashedIO), where transfer flags are not available.
The relevant starting points for fixing this are '[gz]fetchFilePS' in External.hs.