On Wed, Feb 20, 2002 at 02:06:57PM -0800, Greg Stein wrote:
> On Wed, Feb 20, 2002 at 01:50:32PM -0800, Blair Zajac wrote:
> >
> > I'd like to see something that the Perl folks use in their builds. Since
> > they use Perforce and get revision numbers and svn has them too, let's put
> > the revision number of the build into the executable. This'll be handy for
> > debugging purposes when people email us so they can tell us exactly which
> > revision they have an issue with. I'd also like to see this in the HTML
> > output generated by the SVN server.
> >
> > This is something cvs cannot do.
>
> It's something that we can't do either :-)
>
> A given executable can be built from a multi-revision working copy. There
> isn't a way to say "this is exactly revision 1347". It might have parts from
> revision 1204, for example.
GCC deals with this problem by having exactly one file, version.c,
which contains a version number. During development, it reads
something like
const char *const version_string = "3.1 20020219 (experimental)";
which means an experimental snapshot taken sometime in 2002-02-19,
from the development effort leading up to the 3.1 release. Every
night, a cron job checks out this file, bumps the datestamp, and
commits it.
The script to cut a release branch changes "experimental" to
"prerelease" on the branch, and bumps the version number on the trunk
(3.1 -> 3.2). There's two months of QA work between the creation of a
release branch and the initial release from that branch; the cron job
keeps bumping the datestamp the whole time.
The script to roll a prerelease doesn't do anything to the version
number.
The script to roll an actual release checks out version.c, deletes all
of the string but "3.1", checks it in, and tags the tree. Then it
immediately checks version.c back out, bumps the version number (3.1
-> 3.1.1), puts back the datestamp and (prerelease) annotation, and
checks it in again. Finally, it runs "cvs export" from the tag and
builds the tarball. Ideally the tree would be locked against any
other activity during this dance; CVS either doesn't implement that or
makes it too much of a hassle to bother with, we get along fine with
social enforcement of the freeze. The point is that *only* a checkout
or export from that tag gets the unvarnished "3.1".
We pretty much ignore the possibility that some random file might not
be of the same vintage as version.c. It only has granularity of a
day, and release/snapshot tarballs are always consistent.
In a Subversified universe, what I'd like to do is turn the cron job
into a checkout trigger which would put the following information into
the version string:
- the global revision number of the tree being checked out
- the date when that revision was checked in
- the branch's "identity" (experimental/prerelease/release,
which would be encoded into the branch name somehow).
Again this would ignore the possibility that someone had done svn
switch on some file or subdirectory. It would never happen for
tarballs. In a development context, people are expected to know what
they're doing.
Hmm... mimicing the existing version-number algorithm requires more
smarts than can sensibly be put into keywords. I have a vision of
some horrible mailcap-ish markup:
const char version_string[] = "3.1%(%{branch-root}%!release%: \
%{global-revision-date} [%{global-revision-number}] (%{branch-root})%)";
Give me checkout/export triggers instead.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006