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

[Eli Zaretskii]

> Cc: address@hidden, "Stephen J. Turnbull" <address@hidden>, address@hidden,
>  address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> 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.