subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <>
Subject Re: Repository organization for complex project
Date Wed, 13 Oct 2010 19:52:09 GMT
----- Original Message ----

> From: Les Mikesell <>
> 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.



View raw message