[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Repository organization for complex project

From: BRM <bm_witness_at_yahoo.com>
Date: Wed, 13 Oct 2010 12:52:09 -0700 (PDT)

----- Original Message ----

> 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.

$0.02

Ben
Received on 2010-10-13 21:52:50 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.