From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Inadequate branch support in VC Date: Thu, 20 Nov 2014 12:30:52 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20141120173052.GA8690@thyrsus.com> References: <83mw7oa3up.fsf@gnu.org> <86h9xwnww0.fsf@yandex.ru> <831toz826d.fsf@gnu.org> <546E1024.5020707@yandex.ru> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416504743 7733 80.91.229.3 (20 Nov 2014 17:32:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2014 17:32:23 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 20 18:32:16 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 1XrVaa-0001rR-D5 for ged-emacs-devel@m.gmane.org; Thu, 20 Nov 2014 18:32:16 +0100 Original-Received: from localhost ([::1]:36626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrVaZ-0000r1-W3 for ged-emacs-devel@m.gmane.org; Thu, 20 Nov 2014 12:32:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrVZP-0007XB-FG for emacs-devel@gnu.org; Thu, 20 Nov 2014 12:31:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrVZL-0002PU-2o for emacs-devel@gnu.org; Thu, 20 Nov 2014 12:31:03 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:41455 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrVZF-0002DE-Hg; Thu, 20 Nov 2014 12:30:53 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 6D45F382C54; Thu, 20 Nov 2014 12:30:52 -0500 (EST) Content-Disposition: inline In-Reply-To: <546E1024.5020707@yandex.ru> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) 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:177883 Archived-At: Dmitry Gutov : > >But I really think we should have a set of VC > >commands that deal with branches: create them, switch to them, remove > >them, etc. > > Indeed. Maybe less related, but we could also use a 'merge' command > and an 'amend' command (which is a fairly normal action when working > on a branch, and will become more important when change logs are > generated from commit messages). I missed Dmitri's original post, but it happens I was looking at this part of VC just hours ago. Motivation - I'm writing a VC back end for SRC, and this required me to get re-acquainted with the front-end/back-end interface. In brief, it's a pretty messy pile. The sort of good news: there is an amend capability. Nothing newer than svn supports it, though - in particular, the git back end could but does not. (SRC wlll support it.) It's accessed through log-view, which is ... even more confusing than the rest of the code. As regards branching, there was an attempt to support it directly in just two back ends (CVS and RCS) as a bag on the side of the checkin capability, but nothing in VC actually exercised that code. I removed the unused cruft to simplify the interface and at least gesture in the direction of proper orthogonality. That was completely the wrong place to try to do branch switching (but I preserved the unused CVS logic in a comment - we will need to re-use it sometime.) There's another checkout flag case I'm probably going to abolish on my next pass through the code. A revision of t is suppose to force checkout on the current branch (vs. nil which is theoretically checkout on trunk). But in most back ends the revision flag silently does nothing. This was another half-baked attempt to support branching that didn't work. Dmitri is correct. VC needs a set of branching primitives: get-current-branch, set-current-branch, create-branch, delete-branch, rename-branch. And we need a standard way to exercise them in the UI. Both are presently lacking. I also, by the way, removed the "editable" flag on the checkout capability; where it matters (SCCS and RCS) files are now always checked out editable. I'm almost sure the code paths with it bound to nil weren't actually exercised - there's been a lot of drift in this code. In general, the back-end interface is in severe need of attention and a design rethink. Again. I think the number of code paths and back-end methods could be seriously reduced. Can't promise when I'll do it, but I'm at least clearing away the rubble and detritus now. Does anyone active on the list have a direct interest in the CVS code? That's the one problem case that's not easy for me to test. I could use some help verifying that my next round of changes don't break it. -- Eric S. Raymond