Limitations of Emacs' vc when using modern backends

[Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>]

Hi Andre,

In short, the problems with vc could be solved by making the following
three changes.  While I believe that these changes should be fully
backwards-compatible, I'm definitely not claiming I know enough about
the Emacs release schedule to claim they should be in Emacs 22.

1. It should be possible for a backend to override vc-previous-version.

2. vc-previous-version should take the file name in addition to the
   revision.

3. vc should call a backend-specific function (say
   vc-BACKEND-canonical-revision) to normalise a revision name (again,
   one that takes both a revision and a file name) before creating a
   buffer.

(1) CVS uses a very specific model for numbering revisions; not all
systems use sequences of integers that encode a path in an and/or
tree.  Subversion, for example, uses plain integers, while Darcs, Git
and Monotone use opaque tokens (actually SHA1 hashes of something or
something else, but that's irrelevant for our discussion).  Only the
backend can know what the ``previous version'' is.

(2) CVS versions files, while modern systems version trees; the effect
is that the correct ``previous version'' depends on the file name.

To give an example using Subversion, suppose that revision 1 creates
files A and B, revision 2 modifies file A, and revision 3 modifies
file B.  Then vc-darcs-previous-version(3, A) should return 2 (which
it already does), but vc-darcs-previous-version(3, B) should return 1.

(3) Darcs identifies revisions by a 65-character long hash of a bunch
of data, which is not something you want to type.  Because of that,
vc-darcs allows identifying a revision by a number of different means
(see vc-darcs-rev-to-hash if you want the gory details).  This means
that if you use vc-version-other-window and friends, you'll end up
with multiple buffers containing the same revision of a given file.

I believe that the functionality of vc-darcs-rev-to-hash (getting a
canonical revision identifier for a given revision identifier) should
be moved into vc itself, and called whenever vc gets a revision from
the user.  The default implementation would just be the identity, but
it should be possible for a backend to override it.

Because of point (2) above, vc-BACKEND-canonical-revision should be
able to access the file name in addition to the revision.

Thanks for your help,

                                        Juliusz Chroboczek

P.S. I'm not subscribed to the list -- please CC me with any follow-ups.