Couldn't you use the concept of a version number AND a build number where
the version number is your current versioning scheme and is basically
whatever you want to call it, and the build number corresponds to the svn
revision number used to produce the build? This is the system that a lot
of commercial software uses and with svn has the advantage that the build
number actually corresponds to something specific in the system as opposed
to being just some random increment that then has to be cross-referenced
or tagged in the system.
Perhaps you could even expose the build number in your Help -> About or
something equivalent within your application? So a customer might be
running version 2.15 (Build 3754).
Also, I do not understand the relationship between one specific commit and
your new version. Wouldn't a new version typically come after a lot of
commits, and when you get to a stage that you want to produce your release
build you would create a tag for that release in subversion that
identified those revisions?
Just some thoughts.
"Crucius, Wesley" <WCrucius@sandc.com> wrote on 03/25/2004 11:06:32 AM:
> I'm still struggling with this one myself. I understand your
> and I can accept it completely. I just want a way to be able to go to
> repository and get the svn revision that "is" release version XX.YYY of
> application. I don't want want to have to maintain a cross-reference
> independently of svn, and tagging seems to be problemmatic for
> because it really slows down explorer with, for example, 6 projects and
> total of around 200 tagged revisions. So I thought maybe a label
> that manually gets set prior to commits of what would be release
> The problem with this is that there does not appear to be a way to
> what is the revision number of a revision whoose label property has a
> of XX.YYY. Please help me out if I'm missing something... Maybe I'm
> missing the most obvious solution here? Just put the release version
> in the commit message????
Received on Thu Mar 25 17:18:16 2004