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 09:37:07 +0300 Message-ID: <83y4fobegc.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443675903 21564 80.91.229.3 (1 Oct 2015 05:05:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 05:05:03 +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 07:04:57 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 1ZhW35-0004Wo-PI for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 07:04:55 +0200 Original-Received: from localhost ([::1]:37917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhW35-0003Al-7w for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 01:04:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhB0e-0005Fv-2s for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:37:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhB0d-0005x4-1N for emacs-devel@gnu.org; Wed, 30 Sep 2015 02:37:00 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhB0Y-0005vz-Ex; Wed, 30 Sep 2015 02:36:54 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NVH00D008YD9C00@a-mtaout20.012.net.il>; Wed, 30 Sep 2015 09:36:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVH00DQ891G4M20@a-mtaout20.012.net.il>; Wed, 30 Sep 2015 09:36:53 +0300 (IDT) In-reply-to: <560B4899.2070708@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.166 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:190498 Archived-At: > Cc: rms@gnu.org, "Stephen J. Turnbull" , eliz@gnu.org, > dak@gnu.org, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Wed, 30 Sep 2015 05:27:37 +0300 > > On 09/23/2015 08:33 PM, Stefan Monnier wrote: > >>> Yes, M-x vc-commit RET should definitely ignore the "up to date" status. > >> By vc-commit, do you mean vc-next-action, or a new command? > > > > Nowadays (as in "with modern VCS"), vc-next-action can't do much > > beside commit, and `vc-next-action' is also the only command which > > can do "commit". > > It also performs that weird step: "If every file in the VC fileset is > not registered for version control, register the fileset (but don't > commit)", aborting if some of the files in the fileset are unregistered > and others are registered. > > It would make sense to remove it (and commit all selected files), but it > would be nice to know what prompted its existence in the first place. 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. 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? > This could also be dropped (we have a separate command for it): > > "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 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. The only advantage is that it makes the code simpler, but IMO this is an ephemeral advantage: the code is not that complicated, the only thing that might be missing is some comments to explain why some things, such as what described above, are done (because not everyone is familiar with all the back-ends we support). 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. I don't think this is how we should make such decisions.