Re: vc with svn and git

[Karl Fogel]

address@hidden (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  <address@hidden>  (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).