Stefan Sperling wrote:
> On Thu, Dec 24, 2009 at 06:39:17PM +0100, Christian Schoenebeck wrote:
>
>> On Thursday 24 December 2009 17:00:00 Stefan Sperling wrote:
>>
>>> What problem do you really want to solve with this?
>>> Why is svnversion not good enough for your problem?
>>>
>> Since svnversion is a separate application, it has to be embedded in some way,
>> e.g. into a Makefile and then passed to a local script or something which
>> performs the actual substitutions. So this implies everybody who works on the
>> project(s) has to call it more or less explicitly, otherwise the version wont
>> be substituted. Not all projects (e.g. script based applications) however
>> require something to be "built" by a Makefile or something equivalent. So often
>> people won't explicitly call such a script in that case, just to update the
>> version tag somewhere.
>>
>> So best way would be to enforce the version substitution by the version
>> control system.
>>
>
> Sounds like what you really want is client-side hooks, so you can call
> 'svnversion' from a client-side hook (e.g. in something like a post-update
> hook). TortoiseSVN has client-side hooks already, this could be used
> as a reference implementation for similar functionality in the CLI-client.
>
Every couple of years someone comes up with a proposal like this, and it
usually ends with a client-side hooks idea. Beh. Subversion is a version
control system, not a build systam. If you want "current global
revision" to label your builds, use Hudson or Buildbot or the dozon
other build automation systems that are integrated with Subversion.
-- Brane
P.S.: And if you're worried about inadequately labelled developer builds
escaping into the wild, you have much bigger problems in your software
development process than just the absence of a global revision number
keyword.
Received on 2009-12-26 18:08:55 CET