[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: dist.sh and svn_version.h (was: Minor svn_version.h cleanups)

From: Ben Reser <ben_at_reser.org>
Date: 2004-05-14 21:37:08 CEST

On Fri, May 14, 2004 at 07:50:23AM +0100, Branko ??ibej wrote:
> Looking at dist.sh, your concern would be addressed by adding another
> line for SVN_VER_PATCH to that sed script in dist.sh. Then the same
> version would work on both trunk and 1.1.x. This is what I will do.

Ahh good idea.

> On the other hand, I think what dist.sh is doing is excruciatingly
> wrong. The release script shoudl not be changing the numbers in
> svn_version.h, it should be _taking_ the numbers from there. I think
> this is very, very broken. We're saying, "forget about all the effort we
> put into source control and release branch stabilization, the RM is
> right even if she happens to mistype the version number on the command
> line."

My initial reaction was the same as yours. But there are reasons that I
changed my mind.

a) We need to be very careful about when changes to svn_version.h are
committed. If we don't make these changes with dist.sh then they need
to be made by hand and committed to the repo before dist.sh runs. Once
we have a tarball we pass it around and test it before announcing the
release. We have on too many occassions found problems that needed
fixing.

So now we have fix that, commit the change to the repo and rebuild the
tarball. In the meantime everyone checking out the branch has been
building a client that reports itself as the release version.

b) Editing svn_version.h for a release is error prone and tedious. When
I started writing out the steps for how to do a release so I could
remove this code from dist.sh, I found that steps to be difficult to
explain.

Yet the changes are very easy to program into dist.sh. Then the RM
doesn't even have to think about editing svn_version.h.

IMHO the more steps and the more complicated the release process is the
more likely we are to make a mistake.

While typos are possible, I don't think this is a very realistic
concern... If the RM typos the version number the name of the tarball
is going to show it. If they typo the revision that the release is to
be made from then they'll end up with the wrong revision in the tarball
(dist.sh does an export of the path given for the repo at the revision
give). Both of these things should stick out and be obvious when we
test the tarball.

Finally if you read notes/releases.txt you'll note that the changes to
svn_version.h get checked in on the tag.

It may seem unintuitive at first, but I think this is the least error
prone way of doing things given the issues.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 14 21:37:23 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.