darcs

Issue 223 add a --remote-darcs flag

Title add a --remote-darcs flag
Priority feature Status resolved
Milestone Resolved in
Superseder Nosy List ckeen, clf, darcs-devel, dmitry.kurochkin, galbolle, jaredj, kowey, thorkilnaur, tommy, visq
Assigned To visq
Topics ProbablyEasy, SSH, UI

Created on 2006-07-09.13:33:00 by kowey, last changed 2010-03-15.11:02:12 by darcs-devel.

Messages
msg802 (view) Author: kowey Date: 2006-07-09.13:32:56
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.
msg803 (view) Author: droundy Date: 2006-07-09.13:37:17
This sounds reasonable.
-- 
David Roundy
msg860 (view) Author: kowey Date: 2006-08-06.09:04:24
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...
msg1830 (view) Author: kowey Date: 2007-07-14.22:49:52
Not needed.  See http://thread.gmane.org/gmane.comp.version-control.darcs.user/10991
msg5662 (view) Author: kowey Date: 2008-08-23.07:24:02
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 :-)
msg5663 (view) Author: galbolle Date: 2008-08-23.07:33:19
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.
msg6783 (view) Author: kowey Date: 2008-12-07.17:17:54
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.
msg6787 (view) Author: ckeen Date: 2008-12-07.21:49:17
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...
msg9402 (view) Author: visq Date: 2009-11-17.21:55:30
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 ?
msg9403 (view) Author: kowey Date: 2009-11-18.05:43:18
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
msg9944 (view) Author: visq Date: 2010-02-03.17:17:56
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.
msg9948 (view) Author: visq Date: 2010-02-03.21:01:33
Closing this bug, as a --remote-darcs flag is available in darcs 2.4. See 
Bug #1736 for transfer-mode support.
msg10221 (view) Author: darcs-devel Date: 2010-03-15.11:02:09
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.
History
Date User Action Args
2006-07-09 13:33:00koweycreate
2006-07-09 13:37:19droundysetstatus: unread -> unknown
nosy: droundy, tommy, kowey
messages: + msg803
2006-08-06 09:04:28koweysetnosy: droundy, tommy, kowey
messages: + msg860
2007-07-14 22:49:53koweysetstatus: unknown -> wont-fix
nosy: + beschmi
messages: + msg1830
2008-08-23 07:21:33koweylinkissue1025 superseder
2008-08-23 07:24:10koweysettopic: + ProbablyEasy, SSH, UI
nosy: + dagit, galbolle, jaredj
messages: + msg5662
title: add a --remotedarcs flag -> add a --remote-darcs flag
2008-08-23 07:33:25galbollesetnosy: droundy, tommy, beschmi, kowey, dagit, jaredj, galbolle
messages: + msg5663
2008-12-07 17:18:04koweysetstatus: wont-fix -> unknown
nosy: + dmitry.kurochkin, simon, thorkilnaur
messages: + msg6783
2008-12-07 21:30:33ckeensetnosy: + ckeen
assignedto: ckeen
2008-12-07 21:49:27ckeensetnosy: droundy, tommy, beschmi, kowey, dagit, simon, thorkilnaur, jaredj, dmitry.kurochkin, galbolle, ckeen
messages: + msg6787
2008-12-08 15:47:28droundysetnosy: - droundy
2009-01-26 01:46:40clfsetnosy: + clf
2009-08-06 20:40:48adminsetnosy: - beschmi
2009-08-10 23:55:08adminsetnosy: - dagit
2009-08-11 18:07:11koweysetstatus: unknown -> needs-implementation
nosy: tommy, kowey, simon, thorkilnaur, jaredj, dmitry.kurochkin, galbolle, ckeen, clf
2009-08-11 18:08:06koweysetstatus: needs-implementation -> waiting-for
nosy: tommy, kowey, simon, thorkilnaur, jaredj, dmitry.kurochkin, galbolle, ckeen, clf
2009-08-25 17:35:51adminsetnosy: + darcs-devel, - simon
2009-08-27 14:23:16adminsetnosy: tommy, kowey, darcs-devel, thorkilnaur, jaredj, dmitry.kurochkin, galbolle, ckeen, clf
2009-11-17 17:44:33visqsetnosy: + visq
2009-11-17 21:55:38visqsetmessages: + msg9402
2009-11-18 05:43:21koweysetmessages: + msg9403
2010-02-03 17:18:03visqsetassignedto: ckeen -> visq
messages: + msg9944
2010-02-03 21:01:43visqsetstatus: waiting-for -> resolved
messages: + msg9948
2010-03-15 11:02:12darcs-develsetmessages: + msg10221