From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.devel Subject: Re: vc with svn and git Date: Fri, 24 Feb 2017 20:04:54 +0000 Message-ID: References: <87bmtrsdkl.fsf@kwork> <87innzqvfi.fsf@kwork> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1487966738 20454 195.159.176.226 (24 Feb 2017 20:05:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 20:05:38 +0000 (UTC) Cc: "Alfred M. Szmidt" , Emacs Development To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 24 21:05:33 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 1chM7R-0004nr-6Y for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 21:05:33 +0100 Original-Received: from localhost ([::1]:39793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chM7X-0004EV-3S for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 15:05:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chM7O-0004EE-3M for emacs-devel@gnu.org; Fri, 24 Feb 2017 15:05:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chM7M-0008Si-OC for emacs-devel@gnu.org; Fri, 24 Feb 2017 15:05:30 -0500 Original-Received: from mail-vk0-x22c.google.com ([2607:f8b0:400c:c05::22c]:34214) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1chM7K-0008QU-N7; Fri, 24 Feb 2017 15:05:26 -0500 Original-Received: by mail-vk0-x22c.google.com with SMTP id r136so17681921vke.1; Fri, 24 Feb 2017 12:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i3OJ2CS5ckt9A3NmAJABisG3wo9huy0qrl+Iv+a9LJQ=; b=csPVeaHlg6mfUyx17rutLoRVY1Ciw0uqMHn9Cs38XWh1SZH8ZLs7LBZP4Tz13OA0qp 5OtTrGjg40SUvShLnSwl9ZtQ65Ym82lZDb9D2OmCFAjRZjmuH5uXLxUAhQMXxLPdxYzR HzFmmXDnaj2ipdDSyoW3jMCmRxdL0XdBcVTw9dk87/yR0p/m9byTMCJ3TfE6s+1lv0iz d4pgFkrHSzPzl+mhYpjOvdJZwBqk4jX7CU/PKzvjgXxP11i1odElFXBbxSeBgcx7KjKT P2Z0S4FzqfA2WnVnYDFzyVVeAhjpcfxyaTslNqJdejZqHmNAY6+ZFiwpZFN5l8Bai/iM 4BBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i3OJ2CS5ckt9A3NmAJABisG3wo9huy0qrl+Iv+a9LJQ=; b=k+yL+NNnXSgcTf+Weo5RFQQfgh0BL6AdcAgHNpo9rddAWc0o/Pcw3GKfBfkA30Wqon 6tamA0ibYbHgPDz4RVlCB38o83vYpxN+T1ShyYn4JOapGRWeQl0E8tiOdIUyjk73qHF2 +AmGVWq47WrHsxTrxTmXhm19NOKk5PoFPb8MZqz2fPLP47fNsDv/Yj2SaHCg0b3XHwS4 TjZTfi0f/iKg89jJfR1vCxdg1rt1qEW3w0AR0y6mG2EQiqX2d4nuxnStFh4luJYlRuun FGHPmGsehEoMtSQE0a1CgrqLGKkwr9PKp1SeArX0HKgp17DhglE/kXgILm5EadlGrK8E 6B0Q== X-Gm-Message-State: AMke39nBUdRORfW68OzQvhRNa5wlYWxVQycu1ZtkJil8/caKLLm2+/Nl6MbIglL6/dVAKtcVWEH0x5aUR7+mHg== X-Received: by 10.31.93.66 with SMTP id r63mr2012085vkb.126.1487966724534; Fri, 24 Feb 2017 12:05:24 -0800 (PST) Original-Received: by 10.159.37.33 with HTTP; Fri, 24 Feb 2017 12:04:54 -0800 (PST) In-Reply-To: <87innzqvfi.fsf@kwork> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c05::22c 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:212580 Archived-At: On 24 February 2017 at 18:45, Karl Fogel 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, resp= ectively) 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 Thi= ngs Are The Way They Are going on here. > > Alfred, want to have a try at that patch instead? I think it might not b= e 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 t= he `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 e= xtra 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 someth= ing -- so that's a second kind of cache check? -- but then we get to the he= art 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 ther= e 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.