[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RCS, again: another removed functionality: undo last-checkin
From: |
Eli Zaretskii |
Subject: |
Re: RCS, again: another removed functionality: undo last-checkin |
Date: |
Wed, 30 Sep 2015 17:13:53 +0300 |
> 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.
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Eli Zaretskii, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin,
Eli Zaretskii <=
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Eli Zaretskii, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Eli Zaretskii, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08
- RE: RCS, again: another removed functionality: undo last-checkin, Drew Adams, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08
- RE: RCS, again: another removed functionality: undo last-checkin, Drew Adams, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Eli Zaretskii, 2015/10/08
- Re: RCS, again: another removed functionality: undo last-checkin, Dmitry Gutov, 2015/10/08