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 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
