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.
