You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2002/02/20 21:50:32 UTC
Re: versioning rant (was: svn commit: rev 1336 -
trunk/subversion/include)
Greg Stein wrote:
>
> On Wed, Feb 20, 2002 at 12:59:33PM -0600, cmpilato@tigris.org wrote:
> > Author: cmpilato
> > Date: 2002-02-20 18:59 GMT
> > New Revision: 1336
> >
> > Modified:
> > trunk/subversion/include/svn_version.h
> > Log:
> > Lose the (rc2) from the version information.
>
> 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.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Sean Russell <se...@germane-software.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 20 February 2002 02:06 pm, Greg Stein wrote:
> > This is something cvs cannot do.
>
> It's something that we can't do either :-)
I /sort/ of understand, but sort of not.
CVS can /almost/ do this, with $Revision: $, except that there isn't one clear
version # for the whole project.
I understand the comment about bits from different revisions, I think (partial
updates? relocations?), but why wouldn't it be useful to do something
similar to $Revision: $ in the svn client/server executable? If someone does
an 'svn up' or 'svn co' and builds, which is probably the most common
behavior, wouldn't the version number be useful information to include?
- --
|.. "Q: How can you delay milk turning sour?
<|> A: Keep it in the cow."
/|\
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8dDWFP0KxygnleI8RAo9UAJ9fSZlZMdS4tAYmCukvR6ZvCQppHgCgsxQO
fluafM9I7W4mGqaVJz34rDI=
=EL0W
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Zack Weinberg <za...@codesourcery.com>.
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
Re: versioning rant
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Feb 20, 2002 at 03:53:38PM -0800, Justin Erenkrantz wrote:
> Hope you see the problem there - not all files are updated each
> commit. What we seem to want is the latest revision of the
> repository not the individual files. I'm thinking you can't do
> that very easily - the best thing to do is to have a manual
> version number. -- justin
that's a problem for what svn wants, but for what NetBSD wants it
might do.
all you need to be able to do (for what Perry is asking for, I think)
is to tell what version of each file you are building is from. branch
and rev of last update of the file gives you that.
or am i missing something?
-garrett
--
garrett rooney Unix was not designed to stop you from
rooneg@electricjellyfish.net doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Feb 20, 2002 at 06:49:39PM -0500, Garrett Rooney wrote:
> i've been thinking about this, and it seems like a problem best solved
> with keywords.
>
> perhaps a $RepositoryPath$ keyword that expands to the file's actual
> path in the repository, which would show you what branch/tag it's on.
>
> actually, we already have a $URL$ keyword, which looks like it would
> expand to what we want. you combine that with the $rev$ keyword and
> you can have something in each file that uniquely identifies what
> version and what branch it came from.
Hope you see the problem there - not all files are updated each
commit. What we seem to want is the latest revision of the
repository not the individual files. I'm thinking you can't do
that very easily - the best thing to do is to have a manual
version number. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
build a revision (was: Re: versioning rant)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 23, 2002 at 10:49:08PM -0000, Barry Scott wrote:
> Using SourceSafe we solve this problem of a unique number for a build as follows:
>
> checkout build_version.dat and check back in forcing a new revision.
> Ask SourceSafe what the revision number is.
> Use the revision number to create a unique label. SRC_0020 say.
> Then we fetch the source at that label and build it.
>
> I'm assuming we can do the same process with subversion.
Subversion has a single, global revision number. Just ask for that number
and use it for your build. For example:
rev="`svn stat -u README | awk '/^Head/ { print $3 }'`"
svn up -r $rev
Depending on your setup, you might also do that last step as:
svn co REPOS_URL -r $rev -d build-tmp
The basic point is, that you can ask for the head revision, then update or
checkout a working copy for that revision. There isn't a need to create
labels or anything.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: versioning rant
Posted by Barry Scott <ba...@ntlworld.com>.
Using SourceSafe we solve this problem of a unique number for a build as follows:
checkout build_version.dat and check back in forcing a new revision.
Ask SourceSafe what the revision number is.
Use the revision number to create a unique label. SRC_0020 say.
Then we fetch the source at that label and build it.
I'm assuming we can do the same process with subversion.
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Yes, please.
Done.
> Note that revision really means LastChangedRev, and thus
> shouldn't increment for a given file until that file is next
> changed as part of a commit.
Right, and the last revision in which this file changed was 12.
> recorded, and fixes don't hurt either... :-)
Don't i wish. We're lucky i have time to play with Subversion at all ;->.
--
Eric Gillespie, Jr. <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Hmm, looks like they all work except URL:
>
> 0 doc% svn pget svn:keywords index.html
> url rev author date
> 0 doc% tail -5 index.html
> $URL: $ $Rev: 11 $ $Author: epg $<br/>
> $Date: Mon 18 Feb 2002 19:43:08 $
> </p>
>
> Not to mention that it's expanding keywords one revision behind. I
> just committed revision 12, a change to the svn:keywords property, 5
> minutes ago.
>
> This is svn from the trunk about half an hour ago and Apache from HEAD
> a few days ago on Debian/i386 unstable.
>
> Should i submit this to IssueZilla?
Yes, please. Note that revision really means LastChangedRev, and thus
shouldn't increment for a given file until that file is next changed
as part of a commit.
In general the keyword stuff needs more testing; the testing is
planned for the alpha phase, when we're in bugfixing mode anyway. But
any problems found now should certainly be recorded, and fixes don't
hurt either... :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Stein <gs...@lyra.org> writes:
> static const char __id__[] = "$URL$ $Rev$";
> $ svn pset svn:keywords "url rev" foo.c
Hmm, looks like they all work except URL:
0 doc% svn pget svn:keywords index.html
url rev author date
0 doc% tail -5 index.html
$URL: $ $Rev: 11 $ $Author: epg $<br/>
$Date: Mon 18 Feb 2002 19:43:08 $
</p>
Not to mention that it's expanding keywords one revision behind. I
just committed revision 12, a change to the svn:keywords property, 5
minutes ago.
This is svn from the trunk about half an hour ago and Apache from HEAD
a few days ago on Debian/i386 unstable.
Should i submit this to IssueZilla?
--
Eric Gillespie, Jr. <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Feb 20, 2002 at 05:34:48PM -0800, Greg Stein wrote:
> All right... then let's turn this around. It sounds like the URL/rev is
> enough to meet your needs. Can you explain what would make it better?
>
> By "longer than you need", I presume you're referring to the fact that much
> of the URL is going to be replicated? That you really only want a branch
> name (if applicable) ?
>
> For example, maybe you want your ID constants to look like:
>
> static const char __id__[] = "$Root: /trunk$ $Rev: 1141$";
>
> or
>
> static const char __id__[] = "$Root: /tags/0.8$ $Rev: 1141$";
yeah, i can see the URL getting really really long in a large
repository. that's very unreadable...
unfortunately, we don't enforce a repos layout, so a $Root$ type
keyword is not simple...
-garrett
--
garrett rooney Unix was not designed to stop you from
rooneg@electricjellyfish.net doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Greg Stein <gs...@lyra.org> writes:
> All right... then let's turn this around. It sounds like the URL/rev is
> enough to meet your needs. Can you explain what would make it better?
>
> By "longer than you need", I presume you're referring to the fact that much
> of the URL is going to be replicated? That you really only want a branch
> name (if applicable) ?
>
> For example, maybe you want your ID constants to look like:
>
> static const char __id__[] = "$Root: /trunk$ $Rev: 1141$";
>
> or
>
> static const char __id__[] = "$Root: /tags/0.8$ $Rev: 1141$";
What we have right now is:
__KERNEL_RCSID(0, "$NetBSD: isa_machdep.c,v 1.53 2001/11/18 13:48:00 jdolecek Exp $");
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 20, 2002 at 08:07:32PM -0500, Perry E. Metzger wrote:
> Greg Stein <gs...@lyra.org> writes:
... [ using SVN URL/rev keywords ] ...
> The only issue on that -- and this might sound silly but it isn't --
> is that you end up with strings that are a lot longer than you need
> them to be. That might sound silly but it isn't -- you can end up with
> a much less readable string and with lots of wasted space in the
> binaries (and sometimes that can be a LOT of space...)
All right... then let's turn this around. It sounds like the URL/rev is
enough to meet your needs. Can you explain what would make it better?
By "longer than you need", I presume you're referring to the fact that much
of the URL is going to be replicated? That you really only want a branch
name (if applicable) ?
For example, maybe you want your ID constants to look like:
static const char __id__[] = "$Root: /trunk$ $Rev: 1141$";
or
static const char __id__[] = "$Root: /tags/0.8$ $Rev: 1141$";
??
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Greg Stein <gs...@lyra.org> writes:
> I presume that NetBSD uses CVS keywords in every file for this
> identification?
Every file has a CVS keyword. We also have static chars that include
the CVS keywords in strings that get incorporated into executables.
> > perhaps a $RepositoryPath$ keyword that expands to the file's actual
> > path in the repository, which would show you what branch/tag it's on.
> >
> > actually, we already have a $URL$ keyword, which looks like it would
> > expand to what we want. you combine that with the $rev$ keyword and
> > you can have something in each file that uniquely identifies what
> > version and what branch it came from.
>
> Exactly:
The only issue on that -- and this might sound silly but it isn't --
is that you end up with strings that are a lot longer than you need
them to be. That might sound silly but it isn't -- you can end up with
a much less readable string and with lots of wasted space in the
binaries (and sometimes that can be a LOT of space...)
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 20, 2002 at 06:49:39PM -0500, Garrett Rooney wrote:
> On Wed, Feb 20, 2002 at 06:27:58PM -0500, Perry E. Metzger wrote:
>...
> > Speaking from NetBSD (and I'm concerned about making sure NetBSD can
> > use Subversion), we need to be able to identify the revisions of the
> > files that built an executable. That also implies, by the way, that we
> > need to know which branch and revision the version comes from since
> > subversion has only the one revision for the entire repository, thus
> > Wednesdays 1.5 branch and trunk would have the same revision number.
I presume that NetBSD uses CVS keywords in every file for this
identification?
> > When I say "need", I mean "need". I have to be able to figure out what
> > someone is running.
Quite reasonable.
I was just referring to the version number that somebody reports when they
do "svn --version". There is no *single* number that can be reported there,
in a safe manner (unless you build and distribute a binary, in which case
you know what went into the thing). Building from a distro is usually quite
safe (for a single number), too, since it is relatively unlikely that people
will be patching that source tarball they downloading.
> i've been thinking about this, and it seems like a problem best solved
> with keywords.
Sure.
> perhaps a $RepositoryPath$ keyword that expands to the file's actual
> path in the repository, which would show you what branch/tag it's on.
>
> actually, we already have a $URL$ keyword, which looks like it would
> expand to what we want. you combine that with the $rev$ keyword and
> you can have something in each file that uniquely identifies what
> version and what branch it came from.
Exactly:
static const char __id__[] = "$URL$ $Rev$";
Just make sure that you set the svn:keywords property on each of the files
where you actually need to expand those keywords. For example:
$ svn pset svn:keywords "url rev" foo.c
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Feb 20, 2002 at 06:27:58PM -0500, Perry E. Metzger wrote:
>
> Greg Stein <gs...@lyra.org> writes:
> > 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.
>
> Speaking from NetBSD (and I'm concerned about making sure NetBSD can
> use Subversion), we need to be able to identify the revisions of the
> files that built an executable. That also implies, by the way, that we
> need to know which branch and revision the version comes from since
> subversion has only the one revision for the entire repository, thus
> Wednesdays 1.5 branch and trunk would have the same revision number.
>
> When I say "need", I mean "need". I have to be able to figure out what
> someone is running.
i've been thinking about this, and it seems like a problem best solved
with keywords.
perhaps a $RepositoryPath$ keyword that expands to the file's actual
path in the repository, which would show you what branch/tag it's on.
actually, we already have a $URL$ keyword, which looks like it would
expand to what we want. you combine that with the $rev$ keyword and
you can have something in each file that uniquely identifies what
version and what branch it came from.
-garrett
--
garrett rooney Unix was not designed to stop you from
rooneg@electricjellyfish.net doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by "Perry E. Metzger" <pe...@piermont.com>.
Greg Stein <gs...@lyra.org> writes:
> 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.
Speaking from NetBSD (and I'm concerned about making sure NetBSD can
use Subversion), we need to be able to identify the revisions of the
files that built an executable. That also implies, by the way, that we
need to know which branch and revision the version comes from since
subversion has only the one revision for the entire repository, thus
Wednesdays 1.5 branch and trunk would have the same revision number.
When I say "need", I mean "need". I have to be able to figure out what
someone is running.
--
Perry E. Metzger perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 21, 2002 at 04:23:57AM +0100, Branko �ibej wrote:
> Greg Stein wrote:
>...
> >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.
Different. Apache inserts a thing that says "this was built by a developer".
That is different than inserting something stating the quality of the
release. The quality is not determined at the time a tarball is snapped.
> >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.
I agree with the marketing fluff comment :-) In fact, that is partly why
(code)names are used for releases of SourceCast inside CollabNet. The
engineering codes for a (named) release, and later on the marketing guys
decide how they feel like numbering it :-)
However, to have some record of "where you are" in the version numbering,
they have to be stored somewhere. Otherwise, it falls to some out-of-band
human bookkeeping to keep track of the "marketing" numbers. Thus, I believe
they belong in source control.
> 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).
We create tarballs before we know the state of the code. That is part of our
process (for better or worse :-). GCC knows their state before the snaps
because they have a different process.
Personally, I like lightweight and flexible processes, and I feel the GCC
"create a branch and let it sit for two months" is a bit burdensome. Not to
mention on a totally different kind of schedule than us :-) That means that
we'll have a general impression of the code state (e.g. we're pre-alpha now,
we'll be alpha in N weeks, beta sometime later, etc), but when we snap a
tarball, it could be horribly broken on some platform. Or maybe a last
minute checkin horked property commits. Or who knows what...
Well... it seems that I've heard a number of +1 to remove the "rc2" type
tagging (and fewer +1's to keep it), and shift that to the release process.
As always, we can debate further on where to put the 0.9.x type stuff. :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@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
Re: versioning rant
Posted by Greg Stein <gs...@lyra.org>.
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.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: versioning rant (was: svn commit: rev 1336 - trunk/subversion/include)
Posted by Mark Benedetto King <bk...@answerfriend.com>.
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.
>
Revision numbers *and* ./configure options, even.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org