RCS: (vc-next-action 1) only New Backend

RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

Hello


Currently I am running the latest GNU git Emacs version and the vc
version which emacs ships.


In older versions of vc, using the RCS backend it was possible when
running (vc-next-action 1) to move to a different branch
say from 2.10 to 3.1.
The prompt was

"Branch, version, or backend to move to: 

However when I just run that command, I only received the following
prompt:

New backend:

What do I miss is there any variable I could set to obtain the old
behaviour?

Thanks

Uwe Brauer 

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Fri, 18 Sep 2015 17:39:01 +0200
> 
> Currently I am running the latest GNU git Emacs version and the vc
> version which emacs ships.
> 
> 
> In older versions of vc, using the RCS backend it was possible when
> running (vc-next-action 1) to move to a different branch
> say from 2.10 to 3.1.
> The prompt was
> 
> "Branch, version, or backend to move to: 

I still get that same prompt with today's Git master when I type

  C-u C-x v v

> However when I just run that command, I only received the following
> prompt:
> 
> New backend:
> 
> What do I miss is there any variable I could set to obtain the old
> behaviour?

No clue, it works for me.

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

> I still get that same prompt with today's Git master when I type

>   C-u C-x v v

But could you, successfully, with the RCS backend, checkin to a higher
branch point?

> No clue, it works for me.

I think I will contact directly the author. Sorry for the noise this is
more a vc specific question.

Uwe Brauer 

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
> Date: Fri, 18 Sep 2015 22:46:23 +0200
> 
> > I still get that same prompt with today's Git master when I type
> 
> >   C-u C-x v v
> 
> But could you, successfully, with the RCS backend, checkin to a higher
> branch point?

I'm not sure what that means.  Can you give a complete recipe,
starting with "emacs -Q", and tell which parts don't work for you?

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

> I'm not sure what that means.  Can you give a complete recipe,
> starting with "emacs -Q", and tell which parts don't work for you?

First here  is a recipe  which *only* works with the older version of
vc. (For which I have to use Xemacs: its vc version is from 2007)
1. Create a new file.
2. Write a line.
3. Save the file
2. C-x v i register is with RCS
3. (Vc-nect-action) checkout
4. write the second  line, save
5. (vc-next-action) checkin version 1.2
6. (Vc-nect-action) checkout version 1.2
7. Add a new line, save
8. (vc-next-action 1) now in the old VC version you are asked for a
   «new version or backend», you time for example 2.1
9. Voila rev is now 2.1


When I try to follow these steps, running Emacs -Q,  in step 8 I just
receive in the prompt  «New Backend» but not «version».

I found the culprit:

In the *old* vc version the relevant functions were:

(defun vc-rcs-checkin (file rev comment)
(defun vc-checkin (file &optional rev comment initial-contents)


Now they are:
(defun vc-checkin (files backend &optional comment initial-contents)
(defun vc-rcs-checkin (files comment)


There is no argument for rev.

I already contacted the author.

I find this feature allowing rev as an parameter very useful, but I
first want to discuss the issue with the author.

Uwe Brauer 

Re: RCS: (vc-next-action 1) only New Backend

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

> When I try to follow these steps, running Emacs -Q,  in step 8 I just
> receive in the prompt  «New Backend» but not «version».
>
> I found the culprit:
>
> In the *old* vc version the relevant functions were:
>
> (defun vc-rcs-checkin (file rev comment)
> (defun vc-checkin (file &optional rev comment initial-contents)
>
>
> Now they are:
> (defun vc-checkin (files backend &optional comment initial-contents)
> (defun vc-rcs-checkin (files comment)
>
>
> There is no argument for rev.
>
> I already contacted the author.
>
> I find this feature allowing rev as an parameter very useful, but I
> first want to discuss the issue with the author.

IIRC VC was given some significant surgery around the time where Emacs
was migrated to a Git repository in order to better support file-set
check-ins and various workflows for distributed version control systems.

I seem to remember that some RCS-only features were debated and possibly
dropped at that time because ESR (along with a lot of others) were not
terribly sympathetic towards complicating the generic framework because
of the possibility of its continued use (mostly expected to be due to
nostalgia).  Indeed, I switched to using Git even for private one-person
projects a long time ago myself.

So I would not be terribly surprised if Eric happened not to be overly
enthusiastic about reintroducing RCS-only functionality that was weeded
out for reasons of practicality.

-- 
David Kastrup

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 19 Sep 2015 10:46:52 +0200
> Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
> 
> First here  is a recipe  which *only* works with the older version of
> vc. (For which I have to use Xemacs: its vc version is from 2007)
> 1. Create a new file.
> 2. Write a line.
> 3. Save the file
> 2. C-x v i register is with RCS
> 3. (Vc-nect-action) checkout
> 4. write the second  line, save
> 5. (vc-next-action) checkin version 1.2
> 6. (Vc-nect-action) checkout version 1.2
> 7. Add a new line, save
> 8. (vc-next-action 1) now in the old VC version you are asked for a
>    «new version or backend», you time for example 2.1
> 9. Voila rev is now 2.1
> 
> 
> When I try to follow these steps, running Emacs -Q,  in step 8 I just
> receive in the prompt  «New Backend» but not «version».

With the current vc-rcs, you need to do the equivalent of steps 8 and
9 from the shell:

  $ ci -l2.1 FILE

Then kill FILE's buffer and revisit it again.  You can now continue
with versions 2.2, 2.3, etc.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 10:59:24 +0200
> 
> IIRC VC was given some significant surgery around the time where Emacs
> was migrated to a Git repository in order to better support file-set
> check-ins and various workflows for distributed version control systems.
> 
> I seem to remember that some RCS-only features were debated and possibly
> dropped at that time because ESR (along with a lot of others) were not
> terribly sympathetic towards complicating the generic framework because
> of the possibility of its continued use (mostly expected to be due to
> nostalgia).  Indeed, I switched to using Git even for private one-person
> projects a long time ago myself.

However, the Emacs manual still says it's possible:

  When you give a prefix argument to `vc-next-action' (`C-u C-x v v'), it
  still performs the next logical version control operation, but accepts
  additional arguments to specify precisely how to do the operation.

     * You can specify the name of a version control system.  This is
       useful if the fileset can be managed by more than one version
       control system, and Emacs fails to detect the correct one.

     * Otherwise, if using CVS or RCS, you can specify a revision ID.

       If the fileset is modified (or locked), this makes Emacs commit
       with that revision ID.  You can create a new branch by supplying an
       appropriate revision ID (*note Branches::).

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 10:59:24 +0200
> 
> I seem to remember that some RCS-only features were debated and possibly
> dropped at that time because ESR (along with a lot of others) were not
> terribly sympathetic towards complicating the generic framework because
> of the possibility of its continued use (mostly expected to be due to
> nostalgia).

I guess you are referring to this discussion:

  http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01164.html

It talks about "rollback", whereas it seems that what was removed
includes a possibility to tell RCS how to number the version it is
about to commit.

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > Uwe Brauer <oub@mat.ucm.es> writes:


   > I seem to remember that some RCS-only features were debated and possibly
   > dropped at that time because ESR (along with a lot of others) were not
   > terribly sympathetic towards complicating the generic framework because
   > of the possibility of its continued use (mostly expected to be due to
   > nostalgia).  Indeed, I switched to using Git even for private one-person
   > projects a long time ago myself.

   > So I would not be terribly surprised if Eric happened not to be overly
   > enthusiastic about reintroducing RCS-only functionality that was weeded
   > out for reasons of practicality.

Thanks for that upgrade. I am a bit confused: I thought the actual
maintainer of vc is  Andre Spiegel <spiegel@gnu.org>, although I know
that vc was/is Eric's brainchild.

Be it as it may, I have tons of files under RCS, so I am not very keen
to try to migrate them to git. I might give it a try and use the old vc
package Xemacs still ships, but it might not be possible....

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > With the current vc-rcs, you need to do the equivalent of steps 8 and
   > 9 from the shell:

   >   $ ci -l2.1 FILE

I know I have tried this out. But I would not call that a very
comfortable solution, given that emacs vc.el is aimed to to everything
within emacs. :'(

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > However, the Emacs manual still says it's possible:

   >   When you give a prefix argument to `vc-next-action' (`C-u C-x v v'), it
   >   still performs the next logical version control operation, but accepts
   >   additional arguments to specify precisely how to do the operation.

   >      * You can specify the name of a version control system.  This is
   >        useful if the fileset can be managed by more than one version
   >        control system, and Emacs fails to detect the correct one.

   >      * Otherwise, if using CVS or RCS, you can specify a revision ID.

   >        If the fileset is modified (or locked), this makes Emacs commit
   >        with that revision ID.  You can create a new branch by supplying an
   >        appropriate revision ID (*note Branches::).

But as we see from the relevant functions I posted in my last email,
that functionality is gone, so it seems  that the manual is a bit outdated.

Re: RCS: (vc-next-action 1) only New Backend

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Sat, 19 Sep 2015 10:59:24 +0200
>> 
>> I seem to remember that some RCS-only features were debated and possibly
>> dropped at that time because ESR (along with a lot of others) were not
>> terribly sympathetic towards complicating the generic framework because
>> of the possibility of its continued use (mostly expected to be due to
>> nostalgia).
>
> I guess you are referring to this discussion:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01164.html
>
> It talks about "rollback", whereas it seems that what was removed
> includes a possibility to tell RCS how to number the version it is
> about to commit.

Entirely possible that this is what I remembered.  However, the
responsible commit turns out to be a good match to my vague recollection
regarding content, commit message, date and author:

commit 2f4f92007956983e6f5cb5136a57ddaa0cd9428e
Author: Eric S. Raymond <esr@thyrsus.com>
Date:   Mon Dec 1 06:23:10 2014 -0500

    VC API simplification: remove ability to set initial revision.
    
    This hasn't made any sense since RCS, and was a dumb stunt then.
    
    * vc/vc.el and all backends: API simplification; init-revision is
    gone, and vc-registered functions no longer take an initial-revision
    argument.

and so my comments regarding the likely reaction to a wish for
resurrection of that feature are probably not wide off the mark.

-- 
David Kastrup

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > Eli Zaretskii <eliz@gnu.org> writes:

   > Entirely possible that this is what I remembered.  However, the
   > responsible commit turns out to be a good match to my vague recollection
   > regarding content, commit message, date and author:

   > commit 2f4f92007956983e6f5cb5136a57ddaa0cd9428e
   > Author: Eric S. Raymond <esr@thyrsus.com>
   > Date:   Mon Dec 1 06:23:10 2014 -0500

   >     VC API simplification: remove ability to set initial revision.
    
   >     This hasn't made any sense since RCS, and was a dumb stunt then.
    
   >     * vc/vc.el and all backends: API simplification; init-revision is
   >     gone, and vc-registered functions no longer take an initial-revision
   >     argument.

   > and so my comments regarding the likely reaction to a wish for
   > resurrection of that feature are probably not wide off the mark.

So an ignorant question. Is it easily possible to obtain the vc versions
prior to Eric surgery? At least that seems to be a better solution than
trying to use Xemacs vc version from 2007.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 11:35:02 +0200
> 
> 
> 
>    > With the current vc-rcs, you need to do the equivalent of steps 8 and
>    > 9 from the shell:
> 
>    >   $ ci -l2.1 FILE
> 
> I know I have tried this out. But I would not call that a very
> comfortable solution, given that emacs vc.el is aimed to to everything
> within emacs. :'(

I've restored the lost ability, please resync with Git master and try
again.  It worked for me with RCS.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 19 Sep 2015 11:36:45 +0200
> Cc: oub@mat.ucm.es, David Kastrup <dak@gnu.org>, emacs-devel@gnu.org
> 
>    > However, the Emacs manual still says it's possible:
> 
>    >   When you give a prefix argument to `vc-next-action' (`C-u C-x v v'), it
>    >   still performs the next logical version control operation, but accepts
>    >   additional arguments to specify precisely how to do the operation.
> 
>    >      * You can specify the name of a version control system.  This is
>    >        useful if the fileset can be managed by more than one version
>    >        control system, and Emacs fails to detect the correct one.
> 
>    >      * Otherwise, if using CVS or RCS, you can specify a revision ID.
> 
>    >        If the fileset is modified (or locked), this makes Emacs commit
>    >        with that revision ID.  You can create a new branch by supplying an
>    >        appropriate revision ID (*note Branches::).
> 
> But as we see from the relevant functions I posted in my last email,
> that functionality is gone, so it seems  that the manual is a bit outdated.

Not any longer.

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > I've restored the lost ability, please resync with Git master and try
   > again.  It worked for me with RCS.


Thanks I lot I will!

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: oub@mat.ucm.es,  emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 12:00:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> >> Date: Sat, 19 Sep 2015 10:59:24 +0200
> >> 
> >> I seem to remember that some RCS-only features were debated and possibly
> >> dropped at that time because ESR (along with a lot of others) were not
> >> terribly sympathetic towards complicating the generic framework because
> >> of the possibility of its continued use (mostly expected to be due to
> >> nostalgia).
> >
> > I guess you are referring to this discussion:
> >
> >   http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01164.html
> >
> > It talks about "rollback", whereas it seems that what was removed
> > includes a possibility to tell RCS how to number the version it is
> > about to commit.
> 
> Entirely possible that this is what I remembered.  However, the
> responsible commit turns out to be a good match to my vague recollection
> regarding content, commit message, date and author:
> 
> commit 2f4f92007956983e6f5cb5136a57ddaa0cd9428e
> Author: Eric S. Raymond <esr@thyrsus.com>
> Date:   Mon Dec 1 06:23:10 2014 -0500
> 
>     VC API simplification: remove ability to set initial revision.
>     
>     This hasn't made any sense since RCS, and was a dumb stunt then.
>     
>     * vc/vc.el and all backends: API simplification; init-revision is
>     gone, and vc-registered functions no longer take an initial-revision
>     argument.
> 
> and so my comments regarding the likely reaction to a wish for
> resurrection of that feature are probably not wide off the mark.

I already resurrected it.

The motivation for removing that functionality was that it complicates
the back-ends.  I've made the REVISION argument to back-end's checkin
method optional and silently ignored by back-ends that don't support
it, so I don't think the back-ends should be affected, except by
having that optional ignored arg.

There was a similar ability in vc-register.  I didn't restore it,
because one can now register as usual and then immediately checkin a
change with a specific version, thus allowing a reasonably convenient
workaround without any need to change the back-ends yet again.

(If I knew that removing this "rollback" also removes the ability to
force a revision at checkin time, I'd have objected to the removal.
But that never came up, AFAIR; instead, the only issue discussed at
length was the meaning of "rollback" for modern VCSes.)

Re: RCS: (vc-next-action 1) only New Backend

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> (If I knew that removing this "rollback" also removes the ability to
> force a revision at checkin time, I'd have objected to the removal.
> But that never came up, AFAIR; instead, the only issue discussed at
> length was the meaning of "rollback" for modern VCSes.)

I don't think that this commit is really related to the "rollback"
discussion.  There actually is

commit ea8b9df12e38775600e850b8a57add2cf523bde5
Author: Eric S. Raymond <esr@thyrsus.com>
Date:   Thu Dec 11 22:44:32 2014 -0500

    Remove VC rollback method.
    
    * vc/vc.el, vc/vc-hg.el, vc/vc-git.el, vc/vc-hooks.el,
    vc/vc-mtn.el, vc/vc-rcs.el, vc/vc-sccs.el, vc/vc-src.el: rrollback
    method removed, to be replaced in the future by uncommit.

which has an author date 10 days later than the removal of the initial
revision argument.

Anybody interested in the historic context would likely have to check
the 2014-11 and 2014-12 archives of emacs-devel.

-- 
David Kastrup

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: oub@mat.ucm.es,  emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 12:58:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > (If I knew that removing this "rollback" also removes the ability to
> > force a revision at checkin time, I'd have objected to the removal.
> > But that never came up, AFAIR; instead, the only issue discussed at
> > length was the meaning of "rollback" for modern VCSes.)
> 
> I don't think that this commit is really related to the "rollback"
> discussion.

You are right, the commit you've shown is about vc-register, which I
didn't change for the reasons explained in my previous message.

> There actually is
> 
> commit ea8b9df12e38775600e850b8a57add2cf523bde5
> Author: Eric S. Raymond <esr@thyrsus.com>
> Date:   Thu Dec 11 22:44:32 2014 -0500
> 
>     Remove VC rollback method.
>     
>     * vc/vc.el, vc/vc-hg.el, vc/vc-git.el, vc/vc-hooks.el,
>     vc/vc-mtn.el, vc/vc-rcs.el, vc/vc-sccs.el, vc/vc-src.el: rrollback
>     method removed, to be replaced in the future by uncommit.
> 
> which has an author date 10 days later than the removal of the initial
> revision argument.

Maybe, but then the commit which is to blame for Uwe's trouble, viz.:

  commit f83109f0fabe13c0175ca6fe23b475bd8a9d9d99
  Author: Eric S. Raymond <esr@thyrsus.com>
  Date:   Thu Nov 20 02:37:06 2014 -0500

      Remove never-used rev argument from VC's backend checkin methods.

      Alters vc/vc-arch.el, vc/vc-bzr.el, vc/vc-cvs.el, vc/vc-dav.el,
      vc/vc-git.el, vc/vc-hg.el, vc/vc-mtn.el, vc/vc-rcs.el,
      vc/vc-sccs.el, vc/vc-svn.el, vc/vc.el.

      Only the RCS, SCCS, and CVS back ends tried to do anything with it,
      and that code was never exercised. Chiseling away the cruft of
      decades...

was never discussed at all, at least I couldn't find it.  And that is
what I partially resurrected.

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > I already resurrected it.

Right now I cannot compile the latest git commit, again I am faced with
the m17n bug. However this bug was successfully repaired by Handa-san,
I tested it. But somehow his commit is not in the branch, I will contact
him.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 19 Sep 2015 14:29:49 +0200
> 
>    > I already resurrected it.
> 
> Right now I cannot compile the latest git commit, again I am faced with
> the m17n bug.

You could instead take the diffs from commit 9ea6c4d and apply them to
your already-built tree.  Then all you'd need to do is byte-compile
the affected files and restart Emacs, because the files I've changed
aren't preloaded.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/19/2015 01:40 PM, Eli Zaretskii wrote:

> I already resurrected it.
>
> The motivation for removing that functionality was that it complicates
> the back-ends.  I've made the REVISION argument to back-end's checkin
> method optional and silently ignored by back-ends that don't support
> it, so I don't think the back-ends should be affected, except by
> having that optional ignored arg.

Can't the user switch to the desired branch manually, with 
vc-retrieve-tag, before doing the checkin?

If they can, maybe there's no need in taking the step back and reversing 
the cleanup.

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

> Be it as it may, I have tons of files under RCS, so I am not very keen
> to try to migrate them to git.

It should be pretty easy to migrate them to SRC, on the other hand.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 19 Sep 2015 19:05:50 +0300
> 
> On 09/19/2015 01:40 PM, Eli Zaretskii wrote:
> 
> > I already resurrected it.
> >
> > The motivation for removing that functionality was that it complicates
> > the back-ends.  I've made the REVISION argument to back-end's checkin
> > method optional and silently ignored by back-ends that don't support
> > it, so I don't think the back-ends should be affected, except by
> > having that optional ignored arg.
> 
> Can't the user switch to the desired branch manually, with 
> vc-retrieve-tag, before doing the checkin?

That's not what this discussion is about.  It is about the user's
ability to tell RCS to designate the new revision by the given number,
like 3.1, at checkin (a.k.a. "commit") time.

Without this capability, you are forever limited to the 1.x series of
revisions, with the 1 part fixed and the x part monotonously
increasing ad nauseam.  With this feature available, the user can
start with version 0.1, proceed to 0.99, then decide the software is
mature enough to be called 1.0, then bump to 2.0 when some major
feature is added, etc.  Since revision numbers in RCS and similar
VCSes served also as poor man's version tags, not having this ability
takes away an important feature with these VCSes.

> If they can, maybe there's no need in taking the step back and reversing 
> the cleanup.

I cannot in good faith call the removal of a (now optional) argument a
"cleanup", sorry.  Given the importance of the lost functionality, it
just isn't worth it, IMO.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/19/2015 08:35 PM, Eli Zaretskii wrote:

> Without this capability, you are forever limited to the 1.x series of
> revisions, with the 1 part fixed and the x part monotonously
> increasing ad nauseam.  With this feature available, the user can
> start with version 0.1, proceed to 0.99, then decide the software is
> mature enough to be called 1.0, then bump to 2.0 when some major
> feature is added, etc.  Since revision numbers in RCS and similar
> VCSes served also as poor man's version tags, not having this ability
> takes away an important feature with these VCSes.

I see, thank you for the explanation.

> I cannot in good faith call the removal of a (now optional) argument a
> "cleanup", sorry.  Given the importance of the lost functionality, it
> just isn't worth it, IMO.

It *did* make the API better, somewhat.

In case someone has the time to try out a better fix, maybe this feature 
would be better to implement the "assign the revision" functionality in 
a backend-specific way, via a MIME header in the log-edit buffer, the 
same way as we specify "Amend" in Git, or "Author" in most backends.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 13:29:42 -0400
> 
> > Be it as it may, I have tons of files under RCS, so I am not very keen
> > to try to migrate them to git.
> 
> It should be pretty easy to migrate them to SRC, on the other hand.

It might; but then I see no reason for us to require users to do
that.  RCS is still pretty useful on its own right, as long as you
maintain small projects.  Just because some of us don't like it
doesn't mean others could not use it.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: dak@gnu.org, oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 19 Sep 2015 20:41:33 +0300
> 
> > I cannot in good faith call the removal of a (now optional) argument a
> > "cleanup", sorry.  Given the importance of the lost functionality, it
> > just isn't worth it, IMO.
> 
> It *did* make the API better, somewhat.

I think an optional argument that any back-end is free to ignore has a
very low (though non-zero) cost.

> In case someone has the time to try out a better fix, maybe this feature 
> would be better to implement the "assign the revision" functionality in 
> a backend-specific way, via a MIME header in the log-edit buffer, the 
> same way as we specify "Amend" in Git, or "Author" in most backends.

If this could be part of the vc-next-action "dwimish" framework, I
think it would be fine to implement it as you describe.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/19/2015 08:49 PM, Eli Zaretskii wrote:

> I think an optional argument that any back-end is free to ignore has a
> very low (though non-zero) cost.

Either way, it's inappropriate, considering that so few backends support 
this. The only reason to have it is to try to preserve the feature that 
some users rely on.

> If this could be part of the vc-next-action "dwimish" framework, I
> think it would be fine to implement it as you describe.

vc-next-action has been a pretty bad idea for a while.

But in any case, it would be a part of vc-checkin, which is called by 
vc-next-action.

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

>> > Be it as it may, I have tons of files under RCS, so I am not very keen
>> > to try to migrate them to git.
>> It should be pretty easy to migrate them to SRC, on the other hand.
> It might; but then I see no reason for us to require users to do
> that.  RCS is still pretty useful on its own right, as long as you
> maintain small projects.  Just because some of us don't like it
> doesn't mean others could not use it.

Agreed, but adding support to the generic VC code for a feature that
can only exist in that one backend (and is not even very widely used by
users of this backend) is kind of problematic.

I think the closest functionality in current backends might be the
ability to tag revisions, so if we could somehow map VC's support for
tagging to this RCS quirk I'd be a lot more satisfied.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

> In case someone has the time to try out a better fix, maybe this feature
> would be better to implement the "assign the revision" functionality
> in a backend-specific way, via a MIME header in the log-edit buffer, the
> same way as we specify "Amend" in Git, or "Author" in most backends.

Indeed, that'd be a lot cleaner.  No need to add a special argument to
the API which is only used in that one backend.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/19/2015 08:49 PM, Eli Zaretskii wrote:
>> I think an optional argument that any back-end is free to ignore has a
>> very low (though non-zero) cost.

> Either way, it's inappropriate, considering that so few backends
> support this. The only reason to have it is to try to preserve the
> feature that some users rely on.

So what are you suggesting? To leave this feature entirely out, even it
concerns only a few lines of code?

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

   > You could instead take the diffs from commit 9ea6c4d and apply them to
   > your already-built tree.  Then all you'd need to do is byte-compile
   > the affected files and restart Emacs, because the files I've changed
   > aren't preloaded.

Right, but I found it a littly worrying that a commit kanda told me
about, is not really in the main trunk.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/20/2015 12:14 AM, Uwe Brauer wrote:

> So what are you suggesting? To leave this feature entirely out, even it
> concerns only a few lines of code?

I've suggested a different approach to its implementation.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: dak@gnu.org, oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 19 Sep 2015 22:44:59 +0300
> 
> On 09/19/2015 08:49 PM, Eli Zaretskii wrote:
> 
> > I think an optional argument that any back-end is free to ignore has a
> > very low (though non-zero) cost.
> 
> Either way, it's inappropriate, considering that so few backends support 
> this. The only reason to have it is to try to preserve the feature that 
> some users rely on.

I don't see how it could be "inappropriate".  Different back-ends have
different features, and you cannot always have unified APIs without
losing some features, unless you accept the notion of optional
arguments that some back-ends will ignore.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: oub@mat.ucm.es,  emacs-devel@gnu.org
> Date: Sat, 19 Sep 2015 16:18:34 -0400
> 
> >> > Be it as it may, I have tons of files under RCS, so I am not very keen
> >> > to try to migrate them to git.
> >> It should be pretty easy to migrate them to SRC, on the other hand.
> > It might; but then I see no reason for us to require users to do
> > that.  RCS is still pretty useful on its own right, as long as you
> > maintain small projects.  Just because some of us don't like it
> > doesn't mean others could not use it.
> 
> Agreed, but adding support to the generic VC code for a feature that
> can only exist in that one backend (and is not even very widely used by
> users of this backend) is kind of problematic.

This feature is supported by 3 back-ends, not by 1.

> I think the closest functionality in current backends might be the
> ability to tag revisions, so if we could somehow map VC's support for
> tagging to this RCS quirk I'd be a lot more satisfied.

Fine with me.

If this were discussed before the feature was removed, we would
probably have that by now.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sat, 19 Sep 2015 23:14:16 +0200
> 
> >>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > On 09/19/2015 08:49 PM, Eli Zaretskii wrote:
> >> I think an optional argument that any back-end is free to ignore has a
> >> very low (though non-zero) cost.
> 
> > Either way, it's inappropriate, considering that so few backends
> > support this. The only reason to have it is to try to preserve the
> > feature that some users rely on.
> 
> So what are you suggesting? To leave this feature entirely out, even it
> concerns only a few lines of code?

As far as I'm concerned, the feature stays until someone codes an
alternative solution that preserves the functionality.

Re: RCS: (vc-next-action 1) only New Backend

[Uwe Brauer]

> I've restored the lost ability, please resync with Git master and try
> again.  It worked for me with RCS.


I finally obtained a version I could compile, I confirm that you
successfully restored this ability. Thank you again.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sun, 20 Sep 2015 12:05:29 +0200
> 
> > I've restored the lost ability, please resync with Git master and try
> > again.  It worked for me with RCS.
> 
> I finally obtained a version I could compile, I confirm that you
> successfully restored this ability. Thank you again.

Thanks for testing.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/20/2015 09:08 AM, Eli Zaretskii wrote:

> As far as I'm concerned, the feature stays until someone codes an
> alternative solution that preserves the functionality.

If someone picks a key binding to add the new MIME header (as examples, 
vc-git uses `C-c C-s' for Signed-Off-By and `C-c C-e' for Amend), and if 
you agree to perform the manuals update, I can do the coding.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 20 Sep 2015 16:10:36 +0300
> 
> On 09/20/2015 09:08 AM, Eli Zaretskii wrote:
> 
> > As far as I'm concerned, the feature stays until someone codes an
> > alternative solution that preserves the functionality.
> 
> If someone picks a key binding to add the new MIME header (as examples, 
> vc-git uses `C-c C-s' for Signed-Off-By and `C-c C-e' for Amend), and if 
> you agree to perform the manuals update, I can do the coding.

Thanks.

But why does it have to be a separate command?  Can't "C-u C-x v v",
when it calls vc-checkin, present that header in the vc-log buffer, so
that muscle memory doesn't have to change?

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

> But why does it have to be a separate command?  Can't "C-u C-x v v",
> when it calls vc-checkin, present that header in the vc-log buffer, so
> that muscle memory doesn't have to change?

Actually, removing this use of C-u is one of the main benefits, in my mind.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  oub@mat.ucm.es,  emacs-devel@gnu.org
> Date: Sun, 20 Sep 2015 12:27:46 -0400
> 
> > But why does it have to be a separate command?  Can't "C-u C-x v v",
> > when it calls vc-checkin, present that header in the vc-log buffer, so
> > that muscle memory doesn't have to change?
> 
> Actually, removing this use of C-u is one of the main benefits, in my mind.

Probably because you have no use for the feature in the first place.
Otherwise I cannot imagine any reason why removing a prefix argument
would make you happier.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Date: Sun, 20 Sep 2015 20:10:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: oub@mat.ucm.es, emacs-devel@gnu.org, dgutov@yandex.ru
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Dmitry Gutov <dgutov@yandex.ru>,  oub@mat.ucm.es,  emacs-devel@gnu.org
> > Date: Sun, 20 Sep 2015 12:27:46 -0400
> > 
> > > But why does it have to be a separate command?  Can't "C-u C-x v v",
> > > when it calls vc-checkin, present that header in the vc-log buffer, so
> > > that muscle memory doesn't have to change?
> > 
> > Actually, removing this use of C-u is one of the main benefits, in my mind.
> 
> Probably because you have no use for the feature in the first place.

And, btw, the removal of the capability to specify a revision didn't
remove the prefix argument, it just limited its meaning to specifying
a different back-end.

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

> And, btw, the removal of the capability to specify a revision didn't
> remove the prefix argument, it just limited its meaning to specifying
> a different back-end.

That's the point: it leaves the C-u to be used for something else which
is not useful only for RCS but potentially for all backends.

I'm perfectly OK with providing the ability to specify the revision
number to use (in vc-rcs.el).  What I'm opposed to is to add special
support for that in the generic code.  It can all be done within
vc-rcs.el using log-edit-extract-headers.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: oub@mat.ucm.es,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Sun, 20 Sep 2015 15:25:21 -0400
> 
> > And, btw, the removal of the capability to specify a revision didn't
> > remove the prefix argument, it just limited its meaning to specifying
> > a different back-end.
> 
> That's the point: it leaves the C-u to be used for something else which
> is not useful only for RCS but potentially for all backends.
> 
> I'm perfectly OK with providing the ability to specify the revision
> number to use (in vc-rcs.el).  What I'm opposed to is to add special
> support for that in the generic code.  It can all be done within
> vc-rcs.el using log-edit-extract-headers.

Once again, specifying a revision at check-in time is not limited to
RCS, it is also supported by CVS and SCCS.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/20/2015 10:40 PM, Eli Zaretskii wrote:

> Once again, specifying a revision at check-in time is not limited to
> RCS, it is also supported by CVS and SCCS.

The point of freeing C-u (to be used for something else) still stands.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/20/2015 08:10 PM, Eli Zaretskii wrote:

> Probably because you have no use for the feature in the first place.
> Otherwise I cannot imagine any reason why removing a prefix argument
> would make you happier.

The calling convention is contrived as well. Why would "verbose" (the 
advertised meaning of using prefix for vc-next-action) mean the ability 
to input a new revision?

The usual meaning of that word is just that a program outputs more.

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

> Once again, specifying a revision at check-in time is not limited to
> RCS, it is also supported by CVS and SCCS.

Never heard of it used for CVS (and can't find mention of it in "cvs
commit --help").  As for SCCS, it can use that same
log-edit-extract-headers for that.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/21/2015 05:18 AM, Stefan Monnier wrote:

> Never heard of it used for CVS (and can't find mention of it in "cvs
> commit --help").  As for SCCS, it can use that same
> log-edit-extract-headers for that.

'man cvs' has this: "-r tag is available with the commit and history 
commands", which follows a paragraph devoted to "-r tag[:date]".

Overall, it doesn't seem to be that far from a common Git workflow 
element: check out a branch (maybe create it) and commit to it.

If we try hard enough, maybe we could fit both new and old backends into 
one VC workflow. Either split the operation likewise into two, for RCS 
and friends (that would be ideal, provided it's possible; and it'll also 
need a new command that allows creating a new tag/revision/branch), or 
also add the ability to "check out another branch and commit" to Git and 
newer backends.

Re: RCS: (vc-next-action 1) only New Backend

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Once again, specifying a revision at check-in time is not limited to
>> RCS, it is also supported by CVS and SCCS.
>
> Never heard of it used for CVS (and can't find mention of it in "cvs
> commit --help").

Where is the point in version numbers x.y if you are unable to ever
change x?

-- 
David Kastrup

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 20 Sep 2015 23:53:29 +0300
> 
> On 09/20/2015 10:40 PM, Eli Zaretskii wrote:
> 
> > Once again, specifying a revision at check-in time is not limited to
> > RCS, it is also supported by CVS and SCCS.
> 
> The point of freeing C-u (to be used for something else) still stands.

It wasn't freed by removing the functionality we discuss.  It just
changed its meaning, and changed inconsistently: when vc-next-action
is going to call vc-checkout, it still prompts for "Branch, revision,
or backend to move to", and allows a revision to be specified for
back-ends beyond RCS and CVS.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 02:54:22 +0300
> 
> Why would "verbose" (the advertised meaning of using prefix for
> vc-next-action) mean the ability to input a new revision?
> 
> The usual meaning of that word is just that a program outputs more.

I'm okay with renaming that argument to something with a better
mnemonic value.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 05:29:11 +0300
> 
> On 09/21/2015 05:18 AM, Stefan Monnier wrote:
> 
> > Never heard of it used for CVS (and can't find mention of it in "cvs
> > commit --help").  As for SCCS, it can use that same
> > log-edit-extract-headers for that.
> 
> 'man cvs' has this: "-r tag is available with the commit and history 
> commands", which follows a paragraph devoted to "-r tag[:date]".

No, that's the wrong command.  We are talking about "cvs commit".
The CVS manual has this text:

  commit options
  --------------

  [...]

  `-r REVISION'
       Commit to REVISION.  REVISION must be either a branch, or a
       revision on the main trunk that is higher than any existing
       revision number (*note Assigning revisions::).  You cannot commit
       to a specific revision on a branch.

> Overall, it doesn't seem to be that far from a common Git workflow 
> element: check out a branch (maybe create it) and commit to it.
> 
> If we try hard enough, maybe we could fit both new and old backends into 
> one VC workflow. Either split the operation likewise into two, for RCS 
> and friends (that would be ideal, provided it's possible; and it'll also 
> need a new command that allows creating a new tag/revision/branch), or 
> also add the ability to "check out another branch and commit" to Git and 
> newer backends.

I think another possibility is to commit a tag with the specified
REVISION string immediately after committing the current changeset.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 20 Sep 2015 22:18:06 -0400
> Cc: oub@mat.ucm.es, dgutov@yandex.ru, emacs-devel@gnu.org
> 
> > Once again, specifying a revision at check-in time is not limited to
> > RCS, it is also supported by CVS and SCCS.
> 
> Never heard of it used for CVS (and can't find mention of it in "cvs
> commit --help").

  $ cvs --help commit
  Usage: cvs commit [-cRlf] [-m msg | -F logfile] [-r rev] files...
      -c          Check for valid edits before committing.
      -R          Process directories recursively.
      -l          Local directory only (not recursive).
      -f          Force the file to be committed; disables recursion.
      -F logfile  Read the log message from file.
      -m msg      Log message.
      -r rev      Commit to this branch or trunk revision.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Re: RCS: (vc-next-action 1) only New Backend

[Stefan Monnier]

>>> Once again, specifying a revision at check-in time is not limited to
>>> RCS, it is also supported by CVS and SCCS.
>> Never heard of it used for CVS (and can't find mention of it in "cvs
>> commit --help").
> Where is the point in version numbers x.y if you are unable to ever
> change x?

AFAIK in the case of CVS, it's just baggage inherited from RCS.
So indeed, AFAIK there is no point in the leading "1." in CVS
revision numbers.


        Stefan

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/21/2015 09:59 AM, Eli Zaretskii wrote:

>> 'man cvs' has this: "-r tag is available with the commit and history
>> commands", which follows a paragraph devoted to "-r tag[:date]".
>
> No, that's the wrong command.  We are talking about "cvs commit".

We are. The above quote is just as relevant.

If the manual is redundant and/or confusing, don't blame me.

> I think another possibility is to commit a tag with the specified
> REVISION string immediately after committing the current changeset.

Commit a tag? You lost me here.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, oub@mat.ucm.es, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 17:06:12 +0300
> 
> > I think another possibility is to commit a tag with the specified
> > REVISION string immediately after committing the current changeset.
> 
> Commit a tag? You lost me here.

This option in RCS and CVS allows you to put a label on the revision,
giving it the name of your liking.  The equivalent in Git is "git tag",
I think.  So this sequence of commands

  git commit ...
  git tag REVISION
  git push

will do what "ci -rREVISION" does in RCS.

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/21/2015 07:12 PM, Eli Zaretskii wrote:

> This option in RCS and CVS allows you to put a label on the revision,
> giving it the name of your liking.  The equivalent in Git is "git tag",
> I think.  So this sequence of commands

IIUC, the point of doing this (in RCS or CVS) is to adjust the revision 
names of all subsequent commits as well. That's much closer to switching 
the branch.

A tag, in Git, just adds an extra (probably better-readable) name to a 
particular commit, and that's it.

>    git commit ...
>    git tag REVISION
>    git push

Note: you need to add '--tags' to 'git push' to make it push tags.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 19:48:45 +0300
> 
> On 09/21/2015 07:12 PM, Eli Zaretskii wrote:
> 
> > This option in RCS and CVS allows you to put a label on the revision,
> > giving it the name of your liking.  The equivalent in Git is "git tag",
> > I think.  So this sequence of commands
> 
> IIUC, the point of doing this (in RCS or CVS) is to adjust the revision 
> names of all subsequent commits as well. That's much closer to switching 
> the branch.

It can serve both purposes: switch to a branch when REVISION specifies
a branch (as in 1.2.1.1), otherwise commit as the named REVISION.  But
that's another issue.

Yes, this also affects all the subsequent commits, but that cannot be
had with a dVCS.

> A tag, in Git, just adds an extra (probably better-readable) name to a 
> particular commit, and that's it.

Indeed.  But it comes close, and is the most you can have for this
functionality.  So instead of saying we don't support it at all, why
not use tags and say we support it as best as we can?

Re: RCS: (vc-next-action 1) only New Backend

[Dmitry Gutov]

On 09/21/2015 07:59 PM, Eli Zaretskii wrote:

> It can serve both purposes: switch to a branch when REVISION specifies
> a branch (as in 1.2.1.1), otherwise commit as the named REVISION.  But
> that's another issue.

Why another? Isn't it the main use case for specifying revision in this 
discussion?

> Yes, this also affects all the subsequent commits, but that cannot be
> had with a dVCS.

DVCS have a 'switch to branch' operation. It's seemingly different, but 
if the workflows are similar, the operations might look the same from 
the VC standpoint.

> Indeed.  But it comes close, and is the most you can have for this
> functionality.  So instead of saying we don't support it at all, why
> not use tags and say we support it as best as we can?

Using tags here would be a low-value feature, as far as I'm concerned 
(you don't add tags as often as you switch branches). 'git tag' is easy 
to do from he terminal anyway.

Further, you don't usually add the tag to the commit right away (at 
least I don't). Tags usually designate releases or milestones of some 
kind, so first you commit, then you test the result somehow, and only 
then you "bless" it with a tag.

Re: RCS: (vc-next-action 1) only New Backend

[Eli Zaretskii]

> Cc: oub@mat.ucm.es, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 21 Sep 2015 20:33:02 +0300
> 
> On 09/21/2015 07:59 PM, Eli Zaretskii wrote:
> 
> > It can serve both purposes: switch to a branch when REVISION specifies
> > a branch (as in 1.2.1.1), otherwise commit as the named REVISION.  But
> > that's another issue.
> 
> Why another? Isn't it the main use case for specifying revision in this 
> discussion?

No.  The main issue was forcing a revision number on the current
branch.

> > Yes, this also affects all the subsequent commits, but that cannot be
> > had with a dVCS.
> 
> DVCS have a 'switch to branch' operation. It's seemingly different, but 
> if the workflows are similar, the operations might look the same from 
> the VC standpoint.

For switching to another branch, yes, I agree.  But this feature is
useful even when staying on the same branch.

> > Indeed.  But it comes close, and is the most you can have for this
> > functionality.  So instead of saying we don't support it at all, why
> > not use tags and say we support it as best as we can?
> 
> Using tags here would be a low-value feature, as far as I'm concerned 
> (you don't add tags as often as you switch branches). 'git tag' is easy 
> to do from he terminal anyway.
> 
> Further, you don't usually add the tag to the commit right away (at 
> least I don't). Tags usually designate releases or milestones of some 
> kind, so first you commit, then you test the result somehow, and only 
> then you "bless" it with a tag.

IMO, all that, though true, does not invalidate my suggestion.  But I
won't argue anymore.