From: Richard Copley <rcopley@gmail.com>
To: Karl Fogel <kfogel@red-bean.com>
Cc: "Alfred M. Szmidt" <ams@gnu.org>,
Emacs Development <emacs-devel@gnu.org>
Subject: Re: vc with svn and git
Date: Fri, 24 Feb 2017 20:04:54 +0000 [thread overview]
Message-ID: <CAPM58ogNJENpKGPCWpHXF-o7K6nJ7VkXQaQaB9tVFRdE88DBfg@mail.gmail.com> (raw)
In-Reply-To: <87innzqvfi.fsf@kwork>
On 24 February 2017 at 18:45, Karl Fogel <kfogel@red-bean.com> wrote:
> ams@gnu.org (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 <monnier@iro.umontreal.ca> 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.
next prev parent reply other threads:[~2017-02-24 20:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-24 15:23 vc with svn and git Alfred M. Szmidt
2017-02-24 15:35 ` Andreas Schwab
2017-02-24 15:54 ` Alfred M. Szmidt
2017-02-24 17:28 ` Karl Fogel
2017-02-24 17:49 ` Stefan Monnier
2017-02-24 18:11 ` Alfred M. Szmidt
2017-02-24 18:45 ` Karl Fogel
2017-02-24 20:04 ` Richard Copley [this message]
2017-02-24 21:16 ` Stefan Monnier
2017-02-24 21:44 ` Richard Copley
2017-02-25 0:11 ` Stefan Monnier
2017-02-25 8:01 ` Michael Albinus
2017-02-25 13:06 ` Stefan Monnier
2017-02-25 13:18 ` Michael Albinus
2017-02-25 13:36 ` tramp-sh-handle-vc-registered (was: vc with svn and git) Stefan Monnier
2017-02-28 14:54 ` vc with svn and git Alfred M. Szmidt
2017-02-28 18:32 ` Karl Fogel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPM58ogNJENpKGPCWpHXF-o7K6nJ7VkXQaQaB9tVFRdE88DBfg@mail.gmail.com \
--to=rcopley@gmail.com \
--cc=ams@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=kfogel@red-bean.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.