[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vc with svn and git

From: Richard Copley
Subject: Re: vc with svn and git
Date: Fri, 24 Feb 2017 20:04:54 +0000

On 24 February 2017 at 18:45, Karl Fogel <address@hidden> wrote:
> 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

There's no particular reason for even a single directory not to
contain more than one of .svn, .git, RCS, CVS subdirectories and/or ,v
and s. files.
VC should ask what backend to use in case of ambiguity, and there
should be a way to force reprompt.

This would also fix the example of a subdirectory called "rcs" which
is not a place for master files but simply a subdirectory for a
project called "rcs" (the MSYS2-packages repository
https://github.com/Alexpux/MSYS2-packages has such a subdirectory). On
case-insensitive filesystems it's not possible to use that repo
without temporarily taking RCS out of vc-handled backends.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]