On 10/13/2010 2:52 PM, BRM wrote:
>
>> From: Les Mikesell<lesmikesell_at_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
lesmikesell_at_gmail.com
Received on 2010-10-13 22:42:53 CEST