From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: RCS: (vc-next-action 1) only New Backend Date: Sat, 19 Sep 2015 20:35:32 +0300 Message-ID: <83pp1epb17.fsf@gnu.org> References: <87mvwjohyi.fsf@mat.ucm.es> <838u83r6hl.fsf@gnu.org> <87k2rn5ucg.fsf@mat.ucm.es> <837fnmrizs.fsf@gnu.org> <877fnm4wzn.fsf@mat.ucm.es> <876136lr83.fsf@fencepost.gnu.org> <83y4g2pxh3.fsf@gnu.org> <871tdulodu.fsf@fencepost.gnu.org> <83twqqpu91.fsf@gnu.org> <55FD87DE.3030506@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1442684150 21847 80.91.229.3 (19 Sep 2015 17:35:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Sep 2015 17:35:50 +0000 (UTC) Cc: oub@mat.ucm.es, dak@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 19 19:35:41 2015 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 1ZdM32-0001fD-OH for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 19:35:40 +0200 Original-Received: from localhost ([::1]:47148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdM31-0008FB-NP for ged-emacs-devel@m.gmane.org; Sat, 19 Sep 2015 13:35:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdM2v-0008F0-Rw for emacs-devel@gnu.org; Sat, 19 Sep 2015 13:35:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdM2u-0001Fc-Ul for emacs-devel@gnu.org; Sat, 19 Sep 2015 13:35:33 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:37888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdM2p-0001EB-O2; Sat, 19 Sep 2015 13:35:27 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NUX00D00PY8WK00@mtaout27.012.net.il>; Sat, 19 Sep 2015 20:31:52 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUX00207Q14OAB0@mtaout27.012.net.il>; Sat, 19 Sep 2015 20:31:52 +0300 (IDT) In-reply-to: <55FD87DE.3030506@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:190106 Archived-At: > Cc: oub@mat.ucm.es, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 19 Sep 2015 19:05:50 +0300 > > On 09/19/2015 01:40 PM, Eli Zaretskii wrote: > > > I already resurrected it. > > > > The motivation for removing that functionality was that it complicates > > the back-ends. I've made the REVISION argument to back-end's checkin > > method optional and silently ignored by back-ends that don't support > > it, so I don't think the back-ends should be affected, except by > > having that optional ignored arg. > > Can't the user switch to the desired branch manually, with > vc-retrieve-tag, before doing the checkin? That's not what this discussion is about. It is about the user's ability to tell RCS to designate the new revision by the given number, like 3.1, at checkin (a.k.a. "commit") time. Without this capability, you are forever limited to the 1.x series of revisions, with the 1 part fixed and the x part monotonously increasing ad nauseam. With this feature available, the user can start with version 0.1, proceed to 0.99, then decide the software is mature enough to be called 1.0, then bump to 2.0 when some major feature is added, etc. Since revision numbers in RCS and similar VCSes served also as poor man's version tags, not having this ability takes away an important feature with these VCSes. > If they can, maybe there's no need in taking the step back and reversing > the cleanup. I cannot in good faith call the removal of a (now optional) argument a "cleanup", sorry. Given the importance of the lost functionality, it just isn't worth it, IMO.