Re: vc-registered optimization

[Michael Albinus]

Julian Scheid <address@hidden> 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.