On Thu, 10 May 2007, Lübbe Onken wrote:
>> And what happens after you check in another file? The $Rev$
>> keyword is not touched in your version.h file.
> No it isn't. The $Rev$ keyword reflects the revision in which that
> particular file was last changed.
> IMNSHO storing the current revision number of a repository inside a file in
> the repository is for wimps (people who don't trust their own build
> process). Forgive my harsh words, I don't want to start a religious war
> here, but I don't like the idea.
That's fine. We do change the version number for each official
release, but it is nice having every revision tagged, so if people are
mildly clueless about which version they downloaded, we would know, so
when they report a bug, we know if they are running the current release or
We added the version information because people don't remember
which version they downloaded, so we added it to the HTML comments, so if
they give us their URL we can check if they are actually running the
version they say they are.
> We have a version file that contains our software release number (x.y.z)
> which is edited manually and which is under revision control. The repository
> revision number is only added at build time when a release is made.
Right, and then anyone using anything in between "official"
releases are completely untagged.
> You also have to ensure that every client has the client side hook
Correct, that will kill this feature for me, since the ones I care
about the most are the clueless folks, not the developers.
> Clients won't be able to commit, because the version.h file has been
> bumped to the next revision and is always out of date locally even if
> you are working on a totally different section of the software.
No, that is how it works now with post-commit scripts, but with a
client-side script, the version.h wouldn't be in the repository at all.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu May 10 16:20:58 2007