On 10/13/2010 2:52 PM, BRM wrote:
From: Les Mikesell<lesmikes...@gmail.com>
We currently commit component binaries back into tags which are then used by
other things with external references, and final binaries are managed
separately by project, but that seems wrong on several levels.
For the projects we do nightly builds on we use an FTP site that the build
scripts upload the builds to. This is easy enough to script even on Windows -
whether using DOS Batch or Windows Scripting Host.
I'm sure Hudson and other build systems can handle that just fine.
I'd like to find a generic scheme (and one that can be plugged into hudson if
possible) to store build results with a versioning scheme that
doesn't force you to keep them forever because most are obsolete after a few
new builds but that has a close-coupling to the svn version
or at least the tag name of the matching source. But this seems like it
should be a common scenario and not something everyone re-invents differently.
Well, right now I have a lot of projects that don't have a nightly build -
mostly due to how Qt and Visual Studios interact - or rather, the problems in
doing so.
However, you can do a couple things to track this very well and automatically,
partially supported via Subversion's Keyword Substitution.
I use $HeadUrl$ in a number of projects to get the URL, which I then parse to
get a information about the build; for example, if it's a tag then I grab the
release information, or a branch then I build a special branch info to output.
For things like the global revision number you'll need to use 'svnversion' to
capture the output somehow.
The following would probably work for you:
1. Capture the URL somewhere as part of checking it out using $HeadURL$
2. As part of the build script run and capture the output of "svnversion", you
might want to do so with "svn info" too - though this only works if you are NOT
doing an export.
You can then store these with a copy of the source and resulting binaries to
have full traceability.
Alternatively, if you are using "svn co" in the build, just tarball or zip up
the project's sandbox at the end of the build script and save it as a whole -
this will keep ALL the information, URLs, versions, etc; for you - and is very
build system friendly too.
This covers the 'backtrack from binary' scenario as long as you keep
those extra pieces in the zip with them. But I'm looking more for a
filesystem and/or http URL name/path mapping to store the binaries so
you can easily find the currently relevant versions in the first place.
Among other things it should provide a straightforward way to replace
our current svn externals to pull specific libraries into place for
dependent builds, and also map to our branch/tag name structure for qa
and production releases. Maven may be the right answer, but I was
thinking in terms of something that could be viewed as a filesystem -
maybe like alfresco where additional rules can be imposed.
--
Les Mikesell
lesmikes...@gmail.com
