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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  "Stephen J. Turnbull" <address@hidden>,  address@hidden, 
>  address@hidden,  address@hidden
> Date: Wed, 30 Sep 2015 00:53:51 -0400
> 
> > 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.
> 
> Right.  From a modern VCS's point of view, I think vc-next-action just
> doesn't make any sense, and trying to be more clever at guessing what
> the user intended won't get us very far.
> 
> That's why I think we'd be better off providing vc-commit.  AFAIK, all
> other operations provided by vc-next-action can be reached via other
> commands, so the only new command that's really needed is vc-commit.
> 
> Then we can just keep vc-next-action for those old VCSes or for those
> rare users who like it.

That'd be fine with me, at least.

But I still wonder why it won't be better to keep vc-next-action for
supporting a simple CVS-like workflow with dVCSes as well.  In such a
workflow, the only additional step is "push".  We can even ignore
"push", leaving it to the user, in which case the order of operations
in such a simple workflow is exactly the same as with RCS or CVS.  Why
not let people migrate gently, instead of abruptly removing all the
basics they've learned?

> > The section dedicated to "For old-style locking-based version control
> > systems" in vc-next-action's docstring is more convoluted. As long as we're
> > dedicated to supporting them, I'm not sure what change would be appropriate.
> 
> The change I'm hinting at is to declare vc-next-action obsolete

That's too radical, I think.  Keeping vc-next-action only for the
older VCSes doesn't mean it's obsolete in any way, because "obsolete"
means "subject to removal soon", which is not the case here.

> But even if we want to keep it, I think it's important, from a
> design point of view, to make sure that it's never *necessary* to
> use vc-next-action.

I think we are already there: vc-next-action invokes commands that are
all available separately, no?