Atwood, Robert C wrote:
> However this requires some scripting magic to get it into the source
> code. While doing that it's also possibly useful to include the date and
> time of compiling. It all depends upon why you want to have the
> revision, I am assuming that it's for traceability and reproducability.
> I also try to get the compiler version, the compilation flags, build
> system name, and username into the executable code. However, a side
> effect I have not yet fixed means that the file in which this code is
> place is itself tagged as 'modified' ; I think I know the way around
> that but have not yet fixed it.
This is actually not that hard a problem: create a file that is *not*
versioned that is generated by your build process, put whatever you want
into it using the local equivalent of #define, then include that file
into your executable or tarball. This has all of the correct behavior
you are looking for:
1) contains all of the bits you want to track;
2) never shows up as modified (since it isn't versioned);
3) is never out of date with your build, since your build process
generates it (make it a mandatory dependency of everything);
The only drawbacks (that I can think of at the momemnt) are:
a) someone checking out directly from your repository must have all the
same development tools as you do when rolling a tarball (not that
onerous in most cases);
b) you need to generate a source tarball from your build system rather
than just exporting files from your repository (also not that big a
problem, since you want the tarball named with the version information
encoded).
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 3 15:42:21 2007