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

[Michael Albinus]

Kai Großjohann <address@hidden> writes:

> 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.

OK, I've got. I had in mind to use the local cached file *instead* of the
real remote file. This would run into consistency problems.

But if we *always* apply the rsync command, using a local cached file
just for *less to transfer*, it makes sense. Nice idea.

> 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?

Maybe it is worth to instrument Tramp in order to see, whether running
rsync for small files is useful. However, the local file cache shall be
implemented fisrst.

If it doesn't result in performance speedup for small files, we could
apply something similar we do already for scp: for files less then 10KB,
the inline transfer method is used, avoiding the scp overhead of
establishing a new connection.

> *scratches head*

Me too. I will think about, whether it could be implemented easily.

> Kai

Best regards, Michael.