From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: My plans for VC mode Date: Sat, 22 Nov 2014 15:17:02 +0100 Message-ID: <593E5C6A-D8AF-4D15-9A0E-79E43784ACAA@swipnet.se> References: <20141122133351.46279382C23@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1416665848 14234 80.91.229.3 (22 Nov 2014 14:17:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2014 14:17:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 22 15:17:22 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XsBV4-0006Sk-BV for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 15:17:22 +0100 Original-Received: from localhost ([::1]:45585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsBV3-0004S9-RZ for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 09:17:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsBUv-0004RT-Ha for emacs-devel@gnu.org; Sat, 22 Nov 2014 09:17:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsBUq-0001Xx-Bd for emacs-devel@gnu.org; Sat, 22 Nov 2014 09:17:13 -0500 Original-Received: from mailfe07.swip.net ([212.247.154.193]:59152 helo=swip.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsBUq-0001Xi-51 for emacs-devel@gnu.org; Sat, 22 Nov 2014 09:17:08 -0500 X-T2-Spam-Status: No, hits=-0.5 required=5.0 tests=BAYES_05 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 549599192 for emacs-devel@gnu.org; Sat, 22 Nov 2014 15:17:03 +0100 In-Reply-To: <20141122133351.46279382C23@snark.thyrsus.com> X-Mailer: Apple Mail (2.1993) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 212.247.154.193 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178008 Archived-At: Hi. Do you have any plans for async checkin/commit from vc? Jan D. > 22 nov 2014 kl. 14:33 skrev Eric S. Raymond : > > I have noted in previous mail that the VC code lacks a clean set of > primitives to deal with branching. My goal is to fix that. > > In the way is the fact that the VC backend API is still something of > a mess. Everyone who has previously modified it (including me in 2007 > when I did the fileset rewrite) has tried to preserve backward > compatibility to the year zero. As a result, the upper-level code > has never gotten completely divorced from the file-oriented back ends. > > The merge command is a particular trouble spot where the back-end model > pokes upward into what should be VCS-independent - as is revealed > by the ";; FIXME: This is CVS/RCS/SCCS specific." in vc/vc.el. > Because of the code that calls out, SVN merge in particular plain > doesn't work right - it assumes RCS behavior in SVN revision numbers. > > A related effect of trying to preserve backward compatibility is that > the backend API has more entry points than it should and is harder to > understand than it should be. I had my nose rubbed in this writing the > support for SRC. Given the advantages of having written both VC mode > and SRC and the freedom to modify SRC to make VC-mode happy, it was > *way* more difficult than it should have been. > > Accordingly, I have concluded that it is time to chuck backward > compatibility and rewrite tha back-end API, simplifying as radically > as I can and enforcing much stricter separation between the VC upper > layer and the back ends. > > This is going to break out-of-tree back ends - not in any way that is > fundamentally difficult to fix, but it will break them. I've already had > one polite complaint about that in email, but explained that we can't > be stuck with the cruft and the previous design mistakes forever. > > I'm explaining this, while "make bootstrap" runs to test a build, > because it may cause some minor disruptions. I'm a little worried > about breaking CVS support; that back end is both the worst hairball > in the file-oriented group (SCCS/RCS/CVS/SRC) and the one I'm least > able to test well. I could use some help with this if there is > anyone on the list using vc-cvs regularly. > > While I do branching I'm also going to look at removing the elaborate > caching the older back ends use to avoid disk traffic as much as > possible. That made sense when I first wrote it twenty-odd years > ago, but it's been a chronic source of TOCTOU bugs and other > coherency problems ever since. Disks are much faster now; it's > probably time for the state-heuristic stuff to die. > -- > Eric S. Raymond > > The saddest life is that of a political aspirant under democracy. His > failure is ignominious and his success is disgraceful. > -- H.L. Mencken