Re: vc with svn and git

[Karl Fogel <kfogel@red-bean.com>]

ams@gnu.org (Alfred M. Szmidt) writes:
>If /home/ams contains a .svn directory, doing (vc-dir
>"/home/ams/emacs") (which is git repository) results in:
>
>  svn: warning: W155010: The node '/home/ams/emacs' was not found.
>  
>  svn: E200009: Could not display info for all targets because some targets don't exist
>
>This patch puts the SVN backend to come into effect last.

This surprised me.  I don't know the VC code well, but something seems odd here:

Shouldn't VC check in order from deeper to shallower anyway?  That is, if you run

  (vc-dir "/foo/bar/baz/qux")

then it should *first* check "qux", then "baz", then "bar", then "foo", in that order.  If there is a .git subdir anywhere along that upward climb, then the check can stop, because the answer is determined.  It doesn't done matter that some parent above might have an .svn dir, since SVN does not "shadow" a deeper Git (nor vice versa -- the example is the same if you swap .svn and .git).

So the fact that the order in which backends are listed in 'vc-handled-backends' affects anything in this scenario is surprising.  Also, going from deeper to shallower means you don't have to care whether SVN is pre- or post-1.7, i.e., whether the .svn administrative subdirs are per-directory or per-tree.  It works the same either way.

Now, if the way VC determines ownership is by invoking 'svn', 'git', etc externally on the full target, then yes, the order in which it tries backends would matter.  That would be problematic from an efficiency standpoint (and in if implemented without enough error-handling it also has correctness problem, as this thread indicates).  I suppose it has the advantage that it defers knowledge of version control ownership details to the program best positioned to have that knowledge, but in practice, I think ownership is always indicated by a dot-subdir of a certain name, right?  I think at this point we can count on that.  In any case, if an external program is going to be invoked, then if the first one returns error, VC should catch that error and just try the next backend in the list, and so
  on until the list is exhausted, rather than confront the user with the first error.

But IMHO it would be better just to look for the dot directories, in a deeper-to-shallower search.  Is there *any* supported VC backend that isn't just using a dot-directory to store version control metadata?

-Karl

>2017-02-24  Alfred M. Szmidt  <ams@gnu.org>  (tiny change)
>
>	* lisp/vc/vc-hooks.el (vc-handled-backends): Check SVN backend last.
>
>
>diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
>index 47e923c209..7da1244ef5 100644
>--- a/lisp/vc/vc-hooks.el
>+++ b/lisp/vc/vc-hooks.el
>@@ -107,7 +107,7 @@ vc-ignore-dir-regexp
>   :type 'regexp
>   :group 'vc)
> 
>-(defcustom vc-handled-backends '(RCS CVS SVN SCCS SRC Bzr Git Hg Mtn)
>+(defcustom vc-handled-backends '(RCS CVS SCCS SRC Bzr Git Hg Mtn SVN)
>   ;; RCS, CVS, SVN, SCCS, and SRC come first because they are per-dir
>   ;; rather than per-tree.  RCS comes first because of the multibackend
>   ;; support intended to use RCS for local commits (with a remote CVS server).