Re: Emacs 23.1.90 pretest

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> 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.

Which is utterly uninteresting in every respect.  The important thing is
that the version is tagged that has been tested and which is intended to
be released.  Whether or not that tag can be represented as "state of
repository at a certain point of time" is not only irrelevant, but the
point is _exactly_ that one does not want to have some state of the
repository tagged, but the state that has been tested and approved as
_release_.

> 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?

Of course "inconsistent with a dVCS world" is completely nonsense.  The
whole point of dVCS is that you tag what constitutes a version at _your_
local site.  This tag does _not_ apply to anything in a central
repository that is not identical to the version at your local site.

> 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.

I don't see why "state of the repository at time point x" is relevant
for anything.

-- 
David Kastrup