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

[Dmitry Gutov]

On 09/30/2015 09:37 AM, Eli Zaretskii wrote:

> 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.

Registering it is not my end goal. Committing it is.

> 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?

It's just inefficient: I often have a set of new as well as modified 
files that implement a new feature. Before I can commit them, I have to 
hunt the unregistered files in vc-dir (or at least one of them, to press 
M then) and make them registered. If I already marked some registered 
files (because I forgot about the unregistered one), I have to unmark 
them and start from the beginning.

Unless some backends absolutely can't commit unregistered files, we can 
skip that step. And even then, registering them could be a part of a 
backend's checkin implementation.

> > "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 the vc-commit's command implementation, of course. It would make no 
sense there.

> 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.

If a maintainer could make a decision like that without others 
second-guessing them, we could stop discussions like the ones you 
mentioned with "just do XX now". Be it using a new VC command, or the 
command-line.

> The only advantage is that it makes the code
> simpler, but IMO this is an ephemeral advantage: the code is not that
> complicated,

It's complicated enough that it's not easy to implement the generic 
"amend" functionality on top of vc-next-action.

> 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.

That's a misrepresentation of the arguments given in favor of that 
vc-checkin change.

At the end of the day, we should be able to drop features that don't 
make sense for VC. The user can access them via the command-line. As 
long as those aren't used too often, that's not a big loss.