Kai Großjohann <[email protected]> writes: > It's sad, really, I think. Only saving a file can take advantage of > the speedup, and only if some variables are set correctly. We could > speed up C-x C-f sometimes if Tramp were to keep a local cache of > remote files. Then we could use the cache to "prime" the transfer (by > copying the cached file to the temporary file, then using rsync to > update that temporary file). I think this should be doable within the > Emacs framework. > > We could speed up C-x C-s if we could hook into the saving procedure, > and after renaming foo to its backup foo~, we would then copy foo~ > back to foo before using rsync to update its content from the local > copy. I am afraid this might not be doable within the Emacs > framework. > > I wonder if this is worth the effort or not. This would only help > people who use Tramp to edit large remote files on a routinely basis. > Tramp is somewhat optimized for the small-files case (by its inline > transfer methods, which are required for multiple hops (unless Michael > changed this)).
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. rsync could show its advantages, if there would be a special handling inside Tramp. This includes changed implementation for recursive copying of directories. However, both proposal (local cache of files, recursive copying) are already part of the todo list. I do not plan to work on it next time, but I'm open to review patches :-) And maybe somebody has a better wording for the info pages ... > Kai Best regards, Michael. _______________________________________________ Tramp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/tramp-devel
