Thus said Stephan Beal on Tue, 10 Feb 2015 00:27:50 +0100: > > Is there way of cloning the local repository to a remote server > > using ssh? When syncing works, why shouldn't cloning as well?
This can certainly be accomplished using a RemoteForward and a local URL on the remote host. For example (and I tried this on so I know it works): First start serving your Fossils: fossil server C:\path\to\fossils Then kick off a clone as a remote command via SSH: ssh -R 8080:localhost:8080 username@remote fossil clone http://localuser@127.0.0.1:8080/project ./remoteclonename.fossil However, I'm a bit confused by the claim that syncyng works, why not cloning... In what way is sync different? Also, I'm not sure why one would want to do it this way, but it certainly is possible with SSH, but why not just use scp? > > hg doesn't make any difference whether source or destination are > > local or remote, same with scp. But the Fossil documentation says > > that the first parameter can be a URL (also local with file://), but > > the destination always has to be a local file. Aha, so it would seem that this is a slightly different scenario than simply cloning via SSH, and is, in fact, not really relevant to SSH at all. This sounds like bi-directional cloning? Is he not simply asking that, given: fossil clone newproject.fossil http://user@remote:1234/newproject Where /newproject does not yet exist, and then the remote Fossil instance takes care of creating whatever is necessary on the remote side to make /newproject a clone of the project? I suppose such a setup might be useful if your only access to a remote host is via Fossil... but, why? Andy -- TAI64 timestamp: 4000000054d95841 _______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
