Re: Removing rollback from VC mode - request for comment

[Thien-Thi Nguyen <ttn@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

() David Kastrup <dak@gnu.org>
() Thu, 11 Dec 2014 10:43:13 +0100

   > Is it really important to support a VC-mode operation that
   > experience has shown to generally be a Bad Thing,

   We are really talking about RCS here.  RCS is not usually
   shared, at least not network-shared.  I don't see that
   experience has shown rollback to be a bad thing for RCS.
   Experience does not tend to show a lot for RCS anyway
   these days since few people are still using it.

Conceptually, rollback is removing the last commit.

In RCS, this is implemented via ‘rcs -o’ (for "outdate"),
which in its general operation can remove a series of
consecutive non-tip commits, as well. In Git terms, "RCS
outdate" can be likened to both ‘git reset --hard HEAD~1’
(last commit only) and ‘git rebase -i’ + manual omission of
commits in the list (generally).  The ‘git rebase’ is more
powerful because an arbitrary set of commits can be dropped;
they need not be consecutive.

Anyway, this DAG-dicing is not shooting oneself in the foot
if one knows what one's doing.  Personally, i prefer VC not
to (try to) think for me in this regard.  [Already, i am
ready to gripe about "always editable" for RCS -- that's
wrong and embracing it in the name of progress is unwise.
(I'm "ready" but i haven't looked at the new code yet, much
less played w/ it, so there's still time to let my angst boil
over. :-D)]

So, i think "rollback" as a concept is actually not far
enough.  Being able to select arbitrary commits to drop (like
‘d’ and ‘x’ in Dired) is what i'd like to see, in its stead.

Another idea is to modify the "rollback" concept to leave the
working files "as-is" but remove the commit from the repo.

For RCS, this would be ‘co -p ; rcs -o ; mv’ (roughly), and
for Git this would be ‘git reset --mixed HEAD~1’.  On second
thought, using the same name w/ different meaning is indeed a
foot-shooting move, so maybe "step back" is what we want.

If we add "step back", then we can keep "rollback" as an
optional mode of operation (via ‘C-u’).  Or "rollback" can
take ‘C-u’ to mean "step back".  Or there could be a variable
to control things.  Etc.

   > simply to preserve backward compatibility?  How do we
   > evaluate tradeoffs when a featurectomy would reduce
   > maintenance burden and possibly improve the quality of
   > support for new systems?

   I think that rollback may make sense in RCS-based
   workflows.  But I don't think that this should be VC's
   problem.  VC does not provide every functionality for
   every version control system, so think we should be fine
   removing rollback from VC.  VC does not support every Git
   functionality either: if it is really important to people,
   it can be reimplemented in some RCS-specific
   mode/feature/library/command set.

I think if we can extend "rollback" to do something useful,
that would be best.  Dropping features is liberating for the
programmer but unkind for the user.  Being unkind to the old
and ugly is particularly lamentable.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]