From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Unknown Newsgroups: gmane.emacs.devel Subject: My plans for VC mode Date: Sat, 22 Nov 2014 08:33:50 -0500 (EST) Message-ID: <20141122133351.46279382C23@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1416663253 10952 80.91.229.3 (22 Nov 2014 13:34:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Nov 2014 13:34:13 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 22 14:34:07 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 1XsApB-0002bm-NL for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 14:34:05 +0100 Original-Received: from localhost ([::1]:45472 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsApB-0005BM-8Q for ged-emacs-devel@m.gmane.org; Sat, 22 Nov 2014 08:34:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsAp3-0005BA-0h for emacs-devel@gnu.org; Sat, 22 Nov 2014 08:34:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsAoy-0006KM-5a for emacs-devel@gnu.org; Sat, 22 Nov 2014 08:33:56 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:34166 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsAoy-0006KB-1p for emacs-devel@gnu.org; Sat, 22 Nov 2014 08:33:52 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 46279382C23; Sat, 22 Nov 2014 08:33:50 -0500 (EST) Original-From: esr@snark (Eric S. Raymond) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:178003 Archived-At: 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