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: Thu, 01 Oct 2015 22:54:12 +0300 Message-ID: <83fv1u8ivv.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> <83d1x0atb2.fsf@gnu.org> <560C9EDA.3040207@yandex.ru> <83vbar9hv3.fsf@gnu.org> <560D2CFD.50702@yandex.ru> <83a8s2agar.fsf@gnu.org> <560D6F13.3090005@yandex.ru> <83si5u8oik.fsf@gnu.org> <560D899A.4080805@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443729540 16909 80.91.229.3 (1 Oct 2015 19:59:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 19:59:00 +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 21:58:51 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 1Zhk0A-0007f3-QM for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 21:58:50 +0200 Original-Received: from localhost ([::1]:55979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhk09-0004dQ-QV for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 15:58:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhjvw-00027Q-Bm for emacs-devel@gnu.org; Thu, 01 Oct 2015 15:54:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhjvv-0008CB-85 for emacs-devel@gnu.org; Thu, 01 Oct 2015 15:54:28 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhjvr-0008Al-77; Thu, 01 Oct 2015 15:54:23 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NVK00C004HGBV00@a-mtaout22.012.net.il>; Thu, 01 Oct 2015 22:54:21 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVK00CHK4MK8C40@a-mtaout22.012.net.il>; Thu, 01 Oct 2015 22:54:21 +0300 (IDT) In-reply-to: <560D899A.4080805@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:190587 Archived-At: > Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 1 Oct 2015 22:29:30 +0300 > > On 10/01/2015 08:52 PM, Eli Zaretskii wrote: > > > I indeed think that features should rarely be removed, only added. > > Then you must be prepared that at certain point the cost of improving > Emacs will be too much for anyone to do anything of significance to it. That's a very distant possibility. In general, most features are only very loosely coupled, so the complexity increases very slowly, certainly sub-linearly. I don't see why we should be afraid of this happening any time soon. > > Yes, but different VCSes have different internal logic, so something > > might make sense with RCS, but not with Git, or vice versa. That's > > the crux of the problem we are discussing, I think, so the question is > > whether a feature must make sense for every back-end for it to be > > considered as sensible. > > It may be decided on a case-by-case basis, but the question is rather > whether it *could* be decided at all. The exact criterion, "make sense > for at least a half of all backends", or "make sense in at least one of > the modern backends", is up for discussion. I think the popularity of a back-end should also be taken into account. SCCS, for example, is probably not very used. We removed vc-arch some time ago, for the same reasons. > > I think there's a better alternative: start a new front end, which > > will only support a subset of back-ends. Then the elders can > > peacefully continue using the old front-end, which will more or less > > stop being developed, only maintained whenever some of the > > infrastructure changes absolutely require that. > > It's an option indeed, though one that requires a larger investment of > time If it requires more time, then the situation with the existing front-end is not too bad. When it's really bad, forking a new front-end should be much easier. > And what if we make some unfortunate decision WRT to features when > creating the second front-end, too? Wait a few years and create a > third one? We should try not to make unfortunate decisions. > It also assumes that the set of backend commands can be static without > incurring any cost. For old back-ends that no longer see significant development, definitely. > > Muscle memory is what stopping them. It's a powerful thing. > > It's easier to change than a big codebase full of features one is > absolutely not allowed to break. Yes, because someone else needs to change ;-)