Re: tramp (2.1.15); Unclear doc for rsync method

[Kai Großjohann]

On 04/13/2009 11:56 AM, Michael Albinus wrote:
> I'm not confident that we shall go this direction. There is currently
> another discussion about cached file *attributes*, which run out of
> date, when another process on the remote machine changes a file there. I
> fear, we couldn't keep local file caches in sync without serious
> supervision of changes on the remote side, etc.

I think in this case there is not much to worry about, since the worst 
case is no speed up in the file transfer.

If you do "rsync $REMOTE_FILE $LOCAL_FILE", and if rsync does not fail, 
then you can assume that after the command finishes, $LOCAL_FILE is an 
exact copy of $REMOTE_FILE.  This assumption holds regardless of the 
previous contents of $LOCAL_FILE.  So whichever version of the 
$REMOTE_FILE we chance to keep around, it will be fine.  If our version 
is reasonably up to date, then the file transfer goes faster.  If it is 
very wrong, then the file transfer goes at normal speed.

This discussion makes me wonder: What is the use of the rsync method?  
On the one hand, we guess that it is not useful, for most files being 
edited are small.  On the other hand, if people explicitly choose the 
rsync method, then perhaps this is because they expect some benefit from 
it.  And it is clear that they can expect any benefit when editing small 
files.  So perhaps the rsync method user community is exactly that 
subset of the Tramp users who regularly edit large files remotely?

*scratches head*

Kai

PS: I just assume, but haven't tested, that "rsync $REMOTE_FILE 
$NEW_LOCAL_FILE" runs at about the same speed as "rsync $REMOTE_FILE 
$RANDOM_LOCAL_FILE" for the same $REMOTE_FILE.  ($NEW_LOCAL_FILE is a 
file that does not exist, $RANDOM_LOCAL_FILE is an existing file with 
contents that are very different from the contents of the $REMOTE_FILE.  
Perhaps if $RANDOM_LOCAL_FILE is very large then this does not hold?)