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 11:28:42 -0600 Message-ID: <87bmtrsdkl.fsf@kwork> References: Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487957612 12509 195.159.176.226 (24 Feb 2017 17:33:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 17:33:32 +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 18:33:28 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 1chJkE-0002dS-F8 for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 18:33:26 +0100 Original-Received: from localhost ([::1]:38844 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chJkK-0001zX-FG for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 12:33:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chJfk-0004R6-TW for emacs-devel@gnu.org; Fri, 24 Feb 2017 12:28:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chJfi-0005nt-7C for emacs-devel@gnu.org; Fri, 24 Feb 2017 12:28:48 -0500 Original-Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]:33451) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1chJfi-0005nI-27; Fri, 24 Feb 2017 12:28:46 -0500 Original-Received: by mail-it0-x232.google.com with SMTP id d9so13180159itc.0; Fri, 24 Feb 2017 09:28:44 -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=se3TpYP8puiOIEVzcKF+7sloQAOB9SqtnBhTSmpw6rw=; b=n1bn2wHzMc2TcSA1/J911GGKOarj8s3Gnf7Skp8wPutXJHJmJ7QmNysIrTAtaS+pIK uLReTZcfEvwHdv02r2PFxK5CNQgffTne9nai8Ozw8I3/Zsu2qpTEtm72Gm3KVsbRuKkl 3FvZ0iwxRvmPKNevzp0ARBunDgR4NzV7FG87LxYKZ7hCTv5xhvxivV902qSFiGYIuJGr obCt190ZU5UQYsaYEPK8jiIh7oUyEKtVulSCwE6Xh2hvqsQzLce7RFrft+lXN1Ehq+8l LplGVvDpTxGrSEm7dcMceLvnrDMRs1zD4IuvPpVNrh1gUgcaLMPqWylf0zXXiPM+LeVR m73Q== 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=se3TpYP8puiOIEVzcKF+7sloQAOB9SqtnBhTSmpw6rw=; b=irimp77IpaICMj39oDBNBC3WtzkglbJc2BFvTpLuW0Uu2ulwYXMZ4Fy3eyygN5hZ+D SFluhlZPOkDZXl3Vj9lOkt8/kKKaAGAYn2lNsfwCA0CC6iLG5F8NNDYghjiR8Fc5ltA9 intUanjZdXMCWRF6NMrTySzr1jDqAKZ9rGJQnUePzTyfzYOPSHLb8Ql2ZdmLRGXUKAe1 5pjaDC+EG6JpQY7k119514fAq4a7htgLQ4Z1lTyre1m6ujRAZ8HGFt2I/dBQP3I8hmkJ qJJR3aNQY5WuG6URyreduax8UanoQ209GOMRIwIw/klBT1xDAzpqD1c2Tl3XeSpv8SXI f9Wg== X-Gm-Message-State: AMke39kqdaCstiuqOITpgNMGJAgjwLAQ93j1rtDG6BE+fxOqfSlFh/nCsMc+67sOoTMYJw== X-Received: by 10.107.43.5 with SMTP id r5mr3408470ior.26.1487957323513; Fri, 24 Feb 2017 09:28:43 -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 j2sm929619itj.30.2017.02.24.09.28.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Feb 2017 09:28:42 -0800 (PST) In-Reply-To: (Alfred M. Szmidt's message of "Fri, 24 Feb 2017 10:23:25 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c0b::232 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:212574 Archived-At: ams@gnu.org (Alfred M. Szmidt) writes: >If /home/ams contains a .svn directory, doing (vc-dir >"/home/ams/emacs") (which is git repository) results in: > > svn: warning: W155010: The node '/home/ams/emacs' was not found. > > svn: E200009: Could not display info for all targets because some targets don't exist > >This patch puts the SVN backend to come into effect last. This surprised me. I don't know the VC code well, but something seems odd here: Shouldn't VC check in order from deeper to shallower anyway? That is, if you run (vc-dir "/foo/bar/baz/qux") then it should *first* check "qux", then "baz", then "bar", then "foo", in that order. If there is a .git subdir anywhere along that upward climb, then the check can stop, because the answer is determined. It doesn't done matter that some parent above might have an .svn dir, since SVN does not "shadow" a deeper Git (nor vice versa -- the example is the same if you swap .svn and .git). So the fact that the order in which backends are listed in 'vc-handled-backends' affects anything in this scenario is surprising. Also, going from deeper to shallower means you don't have to care whether SVN is pre- or post-1.7, i.e., whether the .svn administrative subdirs are per-directory or per-tree. It works the same either way. Now, if the way VC determines ownership is by invoking 'svn', 'git', etc externally on the full target, then yes, the order in which it tries backends would matter. That would be problematic from an efficiency standpoint (and in if implemented without enough error-handling it also has correctness problem, as this thread indicates). I suppose it has the advantage that it defers knowledge of version control ownership details to the program best positioned to have that knowledge, but in practice, I think ownership is always indicated by a dot-subdir of a certain name, right? I think at this point we can count on that. In any case, if an external program is going to be invoked, then if the first one returns error, VC should catch that error and just try the next backend in the list, and so on until the list is exhausted, rather than confront the user with the first error. But IMHO it would be better just to look for the dot directories, in a deeper-to-shallower search. Is there *any* supported VC backend that isn't just using a dot-directory to store version control metadata? -Karl >2017-02-24 Alfred M. Szmidt (tiny change) > > * lisp/vc/vc-hooks.el (vc-handled-backends): Check SVN backend last. > > >diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el >index 47e923c209..7da1244ef5 100644 >--- a/lisp/vc/vc-hooks.el >+++ b/lisp/vc/vc-hooks.el >@@ -107,7 +107,7 @@ vc-ignore-dir-regexp > :type 'regexp > :group 'vc) > >-(defcustom vc-handled-backends '(RCS CVS SVN SCCS SRC Bzr Git Hg Mtn) >+(defcustom vc-handled-backends '(RCS CVS SCCS SRC Bzr Git Hg Mtn SVN) > ;; RCS, CVS, SVN, SCCS, and SRC come first because they are per-dir > ;; rather than per-tree. RCS comes first because of the multibackend > ;; support intended to use RCS for local commits (with a remote CVS server).