Issue 2462 --remote-darcs gets ignored for transfer-mode

Title --remote-darcs gets ignored for transfer-mode
Priority Status unknown
Milestone Resolved in
Superseder Nosy List bf
Assigned To

Created on 2015-07-02.12:27:38 by bf, last changed 2015-07-02.12:51:09 by bf.

msg18670 (view) Author: bf Date: 2015-07-02.12:27:37
To see this in action, do something with a remote (ssh) repo, specify
--remote-darcs /bla. Here is a real-life example:

> darcs pull
--remote-darcs /bla --debug
Beginning identifying repository .
Done identifying repository .
Identified darcs-2 repo:
Beginning identifying repository
copySSH file:
Disabling progress reports...
Starting new ssh connection to franksen@aragon
Detecting SSH settings
SSH settings: SshSettings {ssh = "ssh", scp = "scp -q", sftp = "sftp"}
ssh franksen@aragon darcs transfer-mode --repodir /opt/repositories

Note the darcs command here (not /bla)

Reenabling progress reports.
Done identifying repository
copySSH file:

... and so on all working well because darcs just uses the default
remote darcs.

Fixing this would be very difficult. copySSH is called by things like
gzFetchFilePS where we don't have the remote darcs option available.

Not sure what to do here.

Perhaps eliminate --remote-darcs option and rely on the user@host's
shell setting to give us the correct darcs in the PATH? (As we do now
anyway for the transfer-mode).
msg18671 (view) Author: bf Date: 2015-07-02.12:51:08
PS: I hate it if people add features in this half-assed way. I mean, it
took me a few grep -r to see that DefaultRemoteDarcs is used in a number
of places, so it became obvious that the option isn't honored
consistently. Whoever added --remote-darcs must have been aware of this.

Very well, if it turns out to be too inconvenient to thread the
parameter through to the end, then please either abandon the effort
(it's not that the feature is essential), or else find a proper solution
(a global mutable variable might be justified here). But don't leave us
with half-working "features" that cannot be relied on to actually work
the way one expects.

Ok, I feel better now. Sorry for the rant. I guess the responsible party
has disappered long ago...
Date User Action Args
2015-07-02 12:27:38bfcreate
2015-07-02 12:51:09bfsetmessages: + msg18671