Greg Stein wrote:
>On Wed, Feb 20, 2002 at 01:50:32PM -0800, Blair Zajac wrote:
>
>>Greg Stein wrote:
>>...
>>
>>>Grrr....
>>>
>>>This means that our 0.9 release actually says "rc2" in it, doesn't it?
>>>
>>>Yup. Just verified.
>>>
>>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.
>
>Our distributions could certainly insert something that specifies the
>revision number, and that a distro was used.
>
>In Apache, the CVS repository (therefore, all developer builds) always say
>something like "2.0.33-dev", meaning that it is being developed towards
>2.0.33. At release time, the -dev is dropped.
>
Heh. So Apache stores the suffix in the repository, and you say that's
good; but so do we, and you say that's bad.
>In our terms, we could have a label that says "dev" and then replace that in
>the "dist.sh" script with the correct revision number. Thus, if people
>report that they are using a "dev" version, we can be suspicious. If they
>report a specific revision, then we know it came from a distro, and what
>revision it was.
>
>Note that this is somewhat orthogonal to including a state / quality level
>in the codebase.
>
No, it is *not*. You could just as well argue that maintaining the
version number in the code base is wrong. After all, version numbers are
nothing but marketing fluff, if your SCM process is solid.
Anyway, I absolutely agre with Zack (not surprising, as I modeled our
svn_version.h file based on what gcc does). We should have a script that
does the Right Thing with the version numbers, suffixes, etc. I've said
before and I'll say again: the state of the code is part of the
configuration. You either keep it all under version control, or you
throw it *all* out (including versin numbers).
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
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