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, again: another removed functionality: undo last-checkin Date: Wed, 30 Sep 2015 17:13:53 +0300 Message-ID: <83d1x0atb2.fsf@gnu.org> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <87eghsfd3m.fsf@fencepost.gnu.org> <83k2rknr2c.fsf@gnu.org> <87mvwellmg.fsf@uwakimon.sk.tsukuba.ac.jp> <56023A6C.3020302@yandex.ru> <5602BE3E.1050009@yandex.ru> <5602C4DE.8020105@yandex.ru> <560B4899.2070708@yandex.ru> <83y4fobegc.fsf@gnu.org> <560BC73C.4040403@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443683018 27897 80.91.229.3 (1 Oct 2015 07:03:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 07:03:38 +0000 (UTC) Cc: stephen@xemacs.org, dak@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 09:03:30 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 1ZhXtn-00070B-Ru for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 09:03:28 +0200 Original-Received: from localhost ([::1]:39285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhXtn-0004FO-6k for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 03:03:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhI9U-0004hM-2E for emacs-devel@gnu.org; Wed, 30 Sep 2015 10:14:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhI9O-000531-4g for emacs-devel@gnu.org; Wed, 30 Sep 2015 10:14:36 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:53332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhI9H-0004zR-KJ; Wed, 30 Sep 2015 10:14:23 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NVH00M00U46SK00@a-mtaout22.012.net.il>; Wed, 30 Sep 2015 17:13:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVH00M5XU78ED90@a-mtaout22.012.net.il>; Wed, 30 Sep 2015 17:13:56 +0300 (IDT) In-reply-to: <560BC73C.4040403@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:190523 Archived-At: > Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Wed, 30 Sep 2015 14:27:56 +0300 > > On 09/30/2015 09:37 AM, Eli Zaretskii wrote: > > > I guess it tries to follow the same workflow that existed initially > > for file-based VCSes: if the file you act on is not registered, the > > most (perhaps the only) reasonable thing to do is register it. > > Registering it is not my end goal. Committing it is. Of course. > > Why are you saying it's weird for modern VCSes? I envision a > > situation where I create several new files and want to add them to > > version control. What situation did you have in mind where what > > vc-next-action currently does makes little or no sense? > > It's just inefficient: I often have a set of new as well as modified > files that implement a new feature. Before I can commit them, I have to > hunt the unregistered files in vc-dir (or at least one of them, to press > M then) and make them registered. If I already marked some registered > files (because I forgot about the unregistered one), I have to unmark > them and start from the beginning. Well, with RCS as the back-end, "register" actually commits. I see that the other back-ends only use the "add" sub-command, but maybe we should change that, so registering ends up with the files committed. I just hope this won't be a big surprise for people who are used to it only adding files without committing them. > Unless some backends absolutely can't commit unregistered files, we can > skip that step. And even then, registering them could be a part of a > backend's checkin implementation. I don't think there are such back-ends. The only issue with such a change that I see is that people might want adding files incrementally, then committing them all at once. If this is something users might do a lot, perhaps we should have a defcustom for such behavior. > >> "For a centralized version control system, if any work file in the VC > >> fileset is out of date, offer to update the fileset." > > > > Are you saying this makes no sense for CVS or SVN? A dVCS is not > > affected, so why drop this? > > In the vc-commit's command implementation, of course. It would make no > sense there. I think it does: if you commit a change in an outdated file, your commit will either be rejected or, worse, will wipe out later commits. > > In general, IMO dropping such features has 2 disadvantages: it causes > > bug reports when users who are used to using them upgrade and find > > they lost them; and spawns endless discussions here that lead nowhere, > > because there are 2 different crowds involved whose opinions cannot be > > easily reconciled. > > If a maintainer could make a decision like that without others > second-guessing them, we could stop discussions like the ones you > mentioned with "just do XX now". Be it using a new VC command, or the > command-line. A maintainer can "just do it", of course, but he/she cannot prevent others from reacting to a commit after the fact. So I don't see any way of avoiding discussions in general. > > In all the years I'm involved with Emacs development, I think the last > > round of changes in VC (I mean the one 9 months or so ago) was the > > first time I saw features dropped not because they are unused or > > incorrectly implemented, but because those who advocated dropping them > > have no use for the back-ends those features support, and some simply > > dislike those back-ends. > > That's a misrepresentation of the arguments given in favor of that > vc-checkin change. If my recollections are wrong, I apologize. I did re-read them when Uwe complained about the change in vc-checkin's behavior. > At the end of the day, we should be able to drop features that don't > make sense for VC. I agree, but the features in question do make sense, I think, because the back-ends they were written for still exist and are supported and used.