Ulrich Eckhardt wrote:
> That said, the revision numbers, which are internal IDs for use by Subversion
> are IMHO a useless thing to put into the version of a program, in particular
> since they change on a per-repository base and not on a per-file or
> per-project base. Explicitly setting a version triple is way cleaner,
> portable between version control systems and actually carries some meaning.
I don't think it's useless at all, it's just useless unless you're very,
very careful about what you do and how you do it.
The problem is that you need to decide what revision number to use, and
you need to make sure that it doesn't lie.
We implemented a system that, just before the compilation (we use
MSBuild, but I'm sure you could implement this sort of thing with Ant or
Make, or whatever your build tool of choice is), scans the working copy
and decides whether it's "clean". "Clean", to us, means that it's not
mixed-revision, has no modified files, has no "disallowed" ignored files
(we only have about 5 that we allow to be ignored), and has no extra
files. If the working copy is deemed "clean", the last two components of
the version number are updated from the revision number (you can't have
more than 4 digits in a component, because win32 uses signed 16-bit
integers to store them). If the working copy is not "clean", the version
number is updated to "0.0.0.0". This makes it very easy to tell where a
specific binary was built from, and makes it extremely trivial to spot a
questionable "development test" binary before it goes anywhere public.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-27 16:54:36 CEST