On 9/11/06, Bryan D. Andrews <bandrews@trendcore.com> wrote:
> I am trying to come up with a way to have our revision number and our
> revision on our assemblyinfo.
>
> I have found a few posts on getting the head revision, but I am
> unclear if anyone is doing it this way:
>
> I want to commit and as I am committing write the revision number to
> the assemblyinfo just before it commits so our entire team has a build
> associated with the revision clearly.
>
> Thanks for any thoughts.
I believe that there is a fundamental flaw in your association of a
build with a commit. Builds are the result of what you have checked out,
not what you happen to commit at any one time. We follow the advice
given in the book (referenced already in this thread), but with some
important differences:
1. We check in a file which contains the "primary" version number of our
component. It usually contains something like "3.1". This is changed as
we move the trunk to the release branch (at least).
2. Our build system automatically generates several representations
suitable for use in different contexts, for example:
A. VERSION_DOTTED = <version file>.<svn rev>.0 [no mixed revs]
or <version file>.<svn rev>.1 [mixed revs]
B. VERSION_COMMA (obvious)
C. VERSION_READABLE = "Release 3.1 (r7200)" or "Release 3.1
(r7200:7300m)"
3. We have a set of standard file translation rules from "f.in" -> "f"
(for example) that automatically replace strings. This allows us to
stamp Word docs, PDFs, as well as assemblies, resource files and source
files.
4. The system also allows a "version modifier" that can be set to
automatically produce things like "3.1B1 (r7500)". This means that when
the beta is finalized we don't change any code, we just remove the
definition of the "version modifier" from our build system, check out
the same revision and rebuild.
The end result is that we can check out any code, build it, and look at
the results to see what was used in the build. There is always the case
of mixed revision working copies. We do not allow that case through our
build system (at least for a single component) but developers frequently
encounter it on their local machines. In that case there is no way to
exactly identify which files where at which versions, but we do know the
range (and that it happened) from the readable string and the "1" at the
end of VERSION_DOTTED.
Just my .02, your mileage will vary.
Bryant Eastham
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 11 16:15:06 2006