Re: Emacs 23.1.90 pretest

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Here's how the scenario I have in mind:
 > 
 >    cvs update
 >    ...blabla build, glance at it, try it out, maybe make a tarball of it...
 >    cvs tag
 >
 > In what way can this be inconsistent with "the One True Repository"?

As you know, CVS commits are not atomic.  You are both wrong when you
write of "One True Repository."  In CVS you simply cannot have a True
Repository in the sense of "true to the Emacs we want to build for
ourselves and distribute to others" without restricting commits to one
developer at a time.

 > In what way is this going to be inconsistent with a checkout by date?

I don't know about your release process, but mine involves testing,
then bumping the version number in configure.ac and version.sh.in, and
putting a release herald in the ChangeLogs, then tagging.  If this
happens:

    cvs update
    ... I build build, test, bump
    ... concurrently, Stefan commits
    cvs commit <exactly the version bump changes, assume no conflicts>
    cvs tag

then the tag spans in time, but does not include, your commit, and in
that sense is inconsistent with checkout by date.

Andreas's procedure using rtag is prohibitively inconvenient, IMO,
because it involves either tagging an untested version or analysis of
changes by others *and* a full test run *after* the tag is created.
If using tag is "inconsistent with a dVCS world", well, what else is
new?

The right way to handle this in CVS IMO is to use "tag", accept the
date/tag inconsistencies for prereleases, and to prohibit commits by
anyone but the release engineer from "cvs update" to "cvs tag" for
public releases.  In that case cvs tag is almost equivalent to cvs
rtag (at least in some versions of CVS there were anomolies having to
do with files that don't exist on the branch being tagged).

Again IMO CVS checkouts by date are only useful for bisection, usually
result in identifying a unique commit, and even if the best you can do
is isolate to a period of say 1 hour with a half-dozen commits, that's
not going to be any worse than (say) bisecting and coming up with the
multi-tty merge as the culprit.  You take a diff and start bisecting
by hunks rather than by time.