----- Original Message ----
> From: Les Mikesell <lesmikesell_at_gmail.com>
> To: BRM <bm_witness_at_yahoo.com>
> 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.
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
Received on 2010-10-13 23:12:00 CEST