software release methodology

[me-5yx05kfkO/aqeI1yJSURBw at public.gmane.org (Matthew Gillen)]

David Kramer wrote:
> I want to expand on a couple of the other areas.
> 
> Matthew Gillen talked about Subversion, and I take issue with some of
> what he said.  First of all, Subversion (my favorite for some years
> now).  has facilities to tweak files before they get checked in, and
> even do things like warn the user if certain conditions are not met,
> etc.  They're called "hook scripts", and that one is called the
> "pre-commit hook script".  In the script's environment are environment
> variables in automatically defined for version, repository URL, etc.
> 
> There's a problem with doing things this way, but it's not really a
> Subversion-specific proble.  It has more to do with using *any* kind of
> method that's not specifically for that purpose in *any* revision
> control system.  That is, the substitution happens before the checkin,
> so the revision number embedded in your code will be the the version
> with your last *fucntional* changes, not the new version with the
> embedded version.

Why not use the post-commit hook then?  That one gets the new revision in it's
 environment.

But what exactly would this hook-script do?  Do a fresh checkout and create a
new .h file with the revision number from the script's environment?  Then you
have one of two cases:  a file that's required to compile, "version.h", is not
available to anyone doing a checkout, or if that version.h /is/ in the
repository, the "release" is always different from the checked in version.

(Naturally, you could solve the first problem by having a makefile rule that
generates a default "version.h" if it does not exist...)

> However, Subversion does offer a very good way to do this that gets
> around this problem nicely.  See
> http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html

My point was that those keywords do /not/ solve this problem nicely.  From
that URL:
> Revision
> This keyword describes the last known revision in which this file changed
> in the repository, and looks something like $Revision: 144 $. It may also
> be specified as LastChangedRevision or Rev.

Note that it sets this on a per-file basis, based on the last revision that
actually touched that file.  So to rely on this, you have to have a particular
file (say, version.h) that gets changed with the last revision before a
release.  But if you have to change a certain file for each release, why
bother trying to incorporate information from the VCS?  Making spurious
changes to a file to "trick" the VCS into doing something bugs me. Why not
just put the version number you want in that special file to begin with?

> (snip from comments re: Nathan Meyers)
> For this reason, it's often much less useful a number than the version (or
> release), which denotes a snapshot of the software you actually care about.
> So maybe this revision thing is overrated.

I agree that versions and revisions are not the same.  You want versions to be
numbers such that technical folk like you and I can infer something based
solely on that number (ie 1.0 means it's got most of it's basic functionality,
unless it's from M$, in which case you need to wait for at least 3.0).  But I
maintain that the easiest way to do this is a checked-in version.h (or
equivalent) that gets updated right before a tag/branch is made.

But there are certain cases where revision numbers are preferred: when you've
got beta-testers (or more specifically, people who are checking out code
directly from the svn repo) and when they file a bug, you want to know exactly
which revision they've got.  For this, the script I mentioned (svnversion) is
probably the best solution, because it will tell you if a given checkout has
mixed revisions and/or local modifications.

Matt

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.