You are mostly right. My original mistake was to rely on the special
behavior of `rsync -r source/ dest` i.e. when the source ends with a
slash, wrongly assuming that scp behaved in the same way. This is what
caused all the trouble to begin with! Instead of fixing this root
cause, I added a fix (102a6eac17) to guard against overwriting an
existing directory, which again worked only because of this special
behavior of rsync, but resulted in the duplicate directory when using
scp (the bug reported here). The correct fix in e71755510, ensures that
the destination directory does not exist on the remote host, so the
difference in behavior no longer matters.
I will follow up with a patch that adds documentation (comments) to the
code and removes the addition of the trailing slash when invoking the
remote copy operation; the latter in order to avoid any difference in
behavior creeping back in. I think I will also add explicit setting of
'export DARCS_SCP=scp' to tests/network/ssh.sh to avoid future
regressions.
|