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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Wed, 30 Sep 2015 14:27:56 +0300
> 
> 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.

Of course.

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

Well, with RCS as the back-end, "register" actually commits.  I see
that the other back-ends only use the "add" sub-command, but maybe we
should change that, so registering ends up with the files committed.
I just hope this won't be a big surprise for people who are used to it
only adding files without committing them.

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

I don't think there are such back-ends.  The only issue with such a
change that I see is that people might want adding files
incrementally, then committing them all at once.  If this is something
users might do a lot, perhaps we should have a defcustom for such
behavior.

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

I think it does: if you commit a change in an outdated file, your
commit will either be rejected or, worse, will wipe out later commits.

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

A maintainer can "just do it", of course, but he/she cannot prevent
others from reacting to a commit after the fact.  So I don't see any
way of avoiding discussions in general.

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

If my recollections are wrong, I apologize.  I did re-read them when
Uwe complained about the change in vc-checkin's behavior.

> At the end of the day, we should be able to drop features that don't 
> make sense for VC.

I agree, but the features in question do make sense, I think, because
the back-ends they were written for still exist and are supported and
used.