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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The "revert" (which IIUC just installs a new change which undoes the
 > effect of some earlier change) can mostly be implemented in
 > a backend-independent way.

As mentioned, that's git terminology; other VCSes use that name for
different operations: hg and bzr check out individual files as of some
revision -- no commit takes place.  For the effect of "git revert", I
believe hg uses "backout", bzr uses a "merge" variant.

 > But the "rollback" (which IIUC can destructively remove an previous
 > existing commit, I guess I'd call it "uncommit")

git has no command to destructively remove commits (except gc --prune,
which by default gives a 60-day grace period IIRC).  "git reset"
simply move the HEAD pointer, and the current branch head if there is
one.

In hg, "rollback" and "strip" are destructive (the commit no longer
exists in the repo), with the caveat that "strip" saves a patch bundle
that can be restored.  (I think it contains enough information to
reproduce the commit.)  bzr "uncommit" appears to be destructive,
although if you save off the revids (not the revno!), you may be able
to merge it back using that information.  (Untested; on consideration,
it's likely that "uncommit" alters the DAG so that the commits cannot
be recovered.)

 > is a lot more problematic, since various backends support it in
 > very different ways with very different limitations.  Generalizing
 > the "Amend:" support of vc-git.el to other backends would probably
 > cover 99% of the use cases.

Mercurial has "commit --amend", similar to the command of the same
name of git's.  For bzr, I would guess you need to uncommit then
commit again (dunno, but I couldn't find a command documented in bzr
help, although Google finds RFEs for "commit --amend" and
"recommit").  LP has a bug with a nice description of the workflow for
bzr: https://bugs.launchpad.net/bzr/+bug/507529.