Re: vc with svn and git

[Karl Fogel]

address@hidden (Alfred M. Szmidt) writes:
>   But IMHO it would be better just to look for the dot directories,
>   in a deeper-to-shallower search.  
>
>That would be a very nice thing.
>
>   Is there *any* supported VC backend that isn't just using a
>   dot-directory to store version control metadata?
>
>The only thing that comes to mind is RCS/SCCS which can store the
>version data beside the original file.

Ah, right.  Sorry, I asked the question in an oversimplified way.  What I 
really meant is: don't all supported VC backends store their metadata in a way 
that can be detected reliably in a walk from deeper to shallower?

The sibling ",v" and "s." files (for RCS- and SCCS-controlled files, 
respectively) can be detected that way, although in those cases it's a two-step 
dance:

  1) First see that both "foo" and "foo,v" (or "s.foo") are present
  2) Then invoke the corresponding backend to make absolutely sure

Stefan Monnier <address@hidden> writes:
> Yes, it should.  It's a long standing limitation: the double loop is
> 
>     (forall backends
>       (forall directory-parents
>         ...))
> 
> instead of
> 
>     (forall directory-parents
>       (forall backends
>         ...))

Okay.  Thanks for confirming that there wasn't some subtle Reason Why Things 
Are The Way They Are going on here.

Alfred, want to have a try at that patch instead?  I think it might not be very 
large.  It looks like `vc-registered' in lisp/vc/vc-hooks.el is the key 
function.

I think there's a caching layer going on -- that appears to be what this block 
is about:

     ((and (boundp 'file-name-handler-alist)
          (setq handler (find-file-name-handler file 'vc-registered)))
      ;; handler should set vc-backend and return t if registered
      (funcall handler 'vc-registered file))

There's no reason the caching layer can't stay in place.  The only thing we're 
concerned with is when there's a cache miss; that's where we get to the `t' 
clause of the `cond':

     (t
      ;; There is no file name handler.
      ;; Try vc-BACKEND-registered for each handled BACKEND.
      ...)

My guess is that's the part Stefan is referring to above.  There's some extra 
complexity in that clause because (I think?) it uses `vc-file-getprop' to check 
if perhaps there's some special backend for this target or something -- so 
that's a second kind of cache check? -- but then we get to the heart of the 
matter, namely, the actual backend invocation:

          (mapc
           (lambda (b)
             (and (vc-call-backend b 'registered file)
                  (vc-file-setprop file 'vc-backend b)
                  (throw 'found t)))

I don't fully understand the caching layer(s).  It almost looks like there are 
*two* possible caches to check: the `vc-registered' handler for that file in 
`file-name-handler-alist', and if that misses, then the `vc-backend' property 
maintained by the VC code itself?  But whatever's going on there, it can stay 
as is.  I think the entire fix here might be just to replace that 'mapc' call 
with a different loop, as per Stefan's comment above.

Best regards,
-Karl