From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: vc with svn and git Date: Fri, 24 Feb 2017 12:45:53 -0600 Message-ID: <87innzqvfi.fsf@kwork> References: <87bmtrsdkl.fsf@kwork> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487964989 23622 195.159.176.226 (24 Feb 2017 19:36:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 19:36:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: ams@gnu.org (Alfred M. Szmidt) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 24 20:36:25 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chLf8-00057Y-RN for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 20:36:19 +0100 Original-Received: from localhost ([::1]:39640 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chLfE-0000Th-Rp for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 14:36:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chKsT-0003Qw-Nx for emacs-devel@gnu.org; Fri, 24 Feb 2017 13:46:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chKsP-0003qK-5a for emacs-devel@gnu.org; Fri, 24 Feb 2017 13:46:01 -0500 Original-Received: from mail-it0-x22b.google.com ([2607:f8b0:4001:c0b::22b]:38420) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1chKsO-0003nS-Nj; Fri, 24 Feb 2017 13:45:56 -0500 Original-Received: by mail-it0-x22b.google.com with SMTP id y135so34850778itc.1; Fri, 24 Feb 2017 10:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=z3dJqq/lmCK3Mv1ei8sxd+ZUXk0w8rxmHrrcsXggYrw=; b=kp8LhWXGxXXHSvfz1s4GNpd48gOqIopK6JixRFUg0uLszVdPPtF1U+54kB4LI3cVkJ kQOzxehCpJQSyKvqzd6TPvxOpd8+XHPstGJ429MVPQYUvCMa50Mjf8WieqrR3eDDy2ka iPIVoTrX6O6HgrJgNXus0KaRLMzMljQb+Q7v/I47vxwkZ/oCgvgrtjD7gcySd6yc1t0+ ZNYMJcUjI9KHjhpE5O16a04S1ieXwFuR6fvDSCJlDF3LaY1YhuMeJ3ZOoNi9ICJaY96d KX4//WXSU0w5nbLD1bss2BrkqczYbXaPS1UjtwpSMt0WqR+PEe78Of/db9ZaSGWf9KI8 8Xxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=z3dJqq/lmCK3Mv1ei8sxd+ZUXk0w8rxmHrrcsXggYrw=; b=QWh/aI/RfTGpDM8WNCa2FQViHbao3ShY0+dMNaTbPE0+5a06MkxWMZrtoCZ+vokakV 58mZxuYpYXwUP0C/LniIq18fMpe5L3HBIBvo8ivrYA9CHnfD30PWFOI5wUGDYgXgnPnU +4vQNyVyHH+4D1Wtp8EuAEm+RXGb4SZK6z+Ml9pc9QlOnYFY0dv9HpJU7ee3T1AfTPOc IgwwAd4b5N/JRPmLjLmBCffmudIReLOf2g3EAzvfWRKRWs3JNryhrkRVeq0L+psW5Pun WMwqis8uxS5kSaEWAHUDH5+CEUE7v1i7DIrp06SfyjvJbnyV5OHzE8yvCDgVxbbueI/u qzoA== X-Gm-Message-State: AMke39ly10MiwmJa3Ieyj7XRZQX5s+tenUNqFQwbs+qFl1VJzf241fQUh7FsTcWFLPLrlA== X-Received: by 10.36.141.69 with SMTP id w66mr3490516itd.96.1487961955596; Fri, 24 Feb 2017 10:45:55 -0800 (PST) Original-Received: from kwork (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id v197sm1265032ita.2.2017.02.24.10.45.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Feb 2017 10:45:54 -0800 (PST) In-Reply-To: (Alfred M. Szmidt's message of "Fri, 24 Feb 2017 13:11:17 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c0b::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212579 Archived-At: 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 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