Re: RCS, again: another removed functionality: undo last-checkin

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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 ;-)