subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Mikesell <lesmikes...@gmail.com>
Subject Re: Repository organization for complex project
Date Wed, 13 Oct 2010 20:42:11 GMT
On 10/13/2010 2:52 PM, BRM wrote:
>
>> From: Les Mikesell<lesmikesell@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@gmail.com


Mime
View raw message