Re: vc-registered optimization

[Julian Scheid]

On Mon, Aug 3, 2009 at 12:21 AM, Michael Albinus<address@hidden> wrote:
> 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.)

Yes, it is not perfect, but don't you think that it's better than the
alternatives (see below)?

How about this: the optimization has to be enabled explicitly by the
user and if enabled, will print a warning when it does have to run
additional remote operations (i.e. when the fallback is executed.)
This way the user would know when the optimization does not (fully)
work.

I think it is fairly unlikely that the files checked for by the
various vc backends will change often, or that new backends will be
added often.

The intricacies of this optimization could also be explained in an
appropriate place such as the user manual. Maybe the list of files to
be checked (per backend) could be moved into defconsts in tramp so
that when there is a discrepancy a savvy user could fix it easily.

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

Yes, I find myself touching files from many sources and it would be
nice to be able to take advantage of Emacs' support for the various
version control frameworks.

More importantly, setting vc-backends to '(git) would only reduce but
not remove this problem: there would still be up to N additional
remote operations, where N is the depth of the file in the filesystem
tree.

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

I agree that this would be the preferable solution but it would
involve cooperation from many people (or would mean a lot of work
doing all this yourself), if I understand the proposal correctly.

I guess in an ideal world, Emacs would provide a generic interface for
batching file operations so this kind of optimization could be applied
to other cases outside of VC.

Cheers,

Julian