On 2013-07-12 01:49, Andy Bradford wrote:
Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200:
I would prefer to not have that option. test-http is for testing a
new
transport method. If you give someone read acces to your ssh repo
then
test-http circumvents that. In fact test-htp makes you while
connected
setup user
I agree with you on this sentiment. Does this also mean, however,
that
you would prefer to remove the original clone behavior entirely?
Right now, the original behavior is preserved by default:
fossil clone ssh://amb@remote//tmp/test.fossil test.fossil
Will invoke a remote shell via SSH, go through the echo/reply
probes,
and then finally launch ``fossil test-http /tmp/test.fossil''.
Should this option be removed entirely? Should it be changed instead
to
go through the same echo/reply probes, but then finally call
``fossil
http /tmp/test.fossil'' instead? Or should the default behavior
be
replaced with simply issuing a remote ``fossil http
/tmp/test.fossil''
as I now do using the -h http option?
My vote would be to remove the original behavior, and replace it
with
simply running a remote ``fossil http /tmp/test.fossil'' and not
worry
about shell issues. But, that does introduce one difference in
behavior
on clones---because the ``fossil http'' command outputs a
Connection: close
header in the response, each interaction during the clone will invoke
a
new SSH command. This isn't necessarily a problem for people who
are
using SSH keys, but you will be prompted for a password each time if
you
aren't using a key. This may not be so bad, however, because I
believe
autosync already behaves this way, so really, it's only the
cloning
operation that would change in behavior.
Perhaps a poll is in order.
Thanks for the feedback.
Andy
--
TAI64 timestamp: 4000000051df44b5
I prefer the new way and do remove the old way
--
Rene
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
