Re: My plans for VC mode

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Eric,

> Accordingly, I have concluded that it is time to chuck backward
> compatibility and rewrite tha back-end API, simplifying as radically
> as I can and enforcing much stricter separation between the VC upper
> layer and the back ends.

Here's hoping it won't be a full rewrite. Aside from serving as a
plumbing for a set of commands, VC is a helpful VCS-agnostic (to a
certain degree) wrapper over a set of commands which third-party
packages can use.

http://elpa.gnu.org/packages/diff-hl.html, for example, uses `vc-state',
as well as `diff', `dir-status' and `dir-status-files', and relies on
their current semantics (even if they're a bit broken in certain
implementations; I intend to improve that).

> While I do branching I'm also going to look at removing the elaborate
> caching the older back ends use to avoid disk traffic as much as
> possible.  That made sense when I first wrote it twenty-odd years
> ago, but it's been a chronic source of TOCTOU bugs and other
> coherency problems ever since.  Disks are much faster now; it's
> probably time for the state-heuristic stuff to die.

Not exactly sure which functions you're referring to here, but an
example of a function in a "newer" backend that uses caching is
`vc-git-root'.

Correctness should trump performance most of the time, but there are
still traffic-sensitive workflows out there, such as TRAMP.