Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii <eliz@gnu.org>]

> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.