Re: vc-registered optimization

[Michael Albinus]

Julian Scheid <address@hidden> writes:

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

Maybe one could go this way, but I'm still not fully convinced that the
majority of the users can apply it. So it shall be rather a (well
documented) hook, where a "savvy user" can add her own optimization.

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

Are this really different version control systems on the same host? I
would expect, that it rather varies, from remote host to remote host (or
remote user to remote user). Then it might be sufficient to provide a
mean to set vc-handled-backends depending on the remote host or user.

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

The current implementation is slow because Tramp must disable file
caches. If a user knows, that no external program changes the vc related
information, one could let her customize, whether a file cache is
enabled, or not. Enabling file caches, performance would remain.

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

Let's lobby for this on emacs-devel :-)

Recently, vc has been rewritten in order to support fileset for its
basic operations. The maintainers shall be aware of such an approach ...

> Cheers,
>
> Julian

Best regards, Michael.