Julian Scheid <[email protected]> writes: > Hi there,
Hi, > Disabling VC backends that I rarely use would be one option but > instead I implemented the attached patch. It changes > tramp-handle-vc-registered to first run a bash script remotely that > checks presence of the files used by the various VC backends in one go > and outputs an S-Expression that can subsequently serve as a cache. > Then tramp-file-name-handler is overridden temporarily by a wrapper > that intercepts file-exists-p, file-readable-p, file-directory-p and > file-executable-p and tries to satisfy these from the cache. That's a nice idea. However, there are disadvantages. You implement a logic in Tramp, which it cannot know consistently: the file names to be checked. This knowledge is completely up to the backends of vc. If a backend changes it checks, or if another backend is added, it doesn't optimize anymore for that backend. Tramp would need to follow all those changes for all vc backends. Tramp would need to be compatible with all used verions of vc, and this for different versions of Emacs, XEmacs, and SXEmacs. And there might be even vc backends nobody of us knows. (I know that you have implemented a fallback for files not known by tramp-vc-file-name-handler. At least, Tramp does not fail.) Is it really the case for you that you work with different vc backends in parallel? If not, setting vc-backends just to '(Git), for example, shall work for you. Another option might be to introduce vc basic operations not only for a single file, but a fileset. Then vc could ask for the existence of several files in one step, which would allow Tramp to implement optimization without knowledge of involved file names (because they would be arguments of that operation). Something which I have also on my wish list is an inotify-like mechanism on remote hosts. Being notified when a remote file is changed would allow Tramp to keep its cache, and to adjust the cache for a given file when a change-event for this file arrives. > Cheers, > > Julian Best regards, Michael. _______________________________________________ Tramp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/tramp-devel
