subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <bm_witn...@yahoo.com>
Subject Re: Repository organization for complex project
Date Wed, 13 Oct 2010 21:11:18 GMT
----- Original Message ----

> From: Les Mikesell <lesmikesell@gmail.com>
> To: BRM <bm_witness@yahoo.com>
> 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.

I actually have the $HeadUrl$ going into a source file in such a way as it is 
actually in the final build (since I actually parse it at run-time). If I ever 
edited the binary I would be able to read the URL.
You can do the same with the others if you like, but getting them there can be 
more problematic and is build system specific on how to do so.

The rest of it was per your statement:

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

So you only keep the tarballs around as long as you like. You could 
alternatively toss them back into SVN, but then you'd be "keeping them forever".

Any how, just $0.02. Apply as desired.

Ben


Mime
View raw message