On Thu, 2007-04-05 at 09:42 +0200, Erik Huelsmann wrote:
> On 4/5/07, Mark Reibert <svn@reibert.com> wrote:
> > Forgive me for asking a question whose answer is presumably obvious to
> > the regulars, but as an outsider I am left wondering if something went
> > "wrong" in the SCM process to cause such difficulty in reconstructing a
> > previous (albeit older) release?
>
> The release manager function has been run by different persons, so
> *if* they would have retained their build environments, they may not
> be the ones trying to get this release out (or even be available at
> this time).
In my day job we have an Anaconda kickstart file that produces our build
machine. Before each release we kickstart up a clean build machine,
build our product from scratch on this machine, and run it through our
test group.
This particular technique is, of course, specific to Red Hat-based
distributions, but perhaps something similar could be used for
Subversion releases. By checking in the kickstart alongside the SVN
sources the official build environment is allowed to change with
releases.
This approach is not meant to dissuade people from using their
distribution of choice (there is good test value in that). Rather it
simply places a stake in the ground by defining a canonical build
environment controlled under CM.
> > Are the dependencies not fully documented? Has the build environment
> > changed? Or is this simply a matter of resource availability for
> > testing?
>
> No, the dependencies have been documented - and are included in many
> cases in the tarball -, but given that 1.0 was released more than 3
> years ago, dependencies of have evolved a lot (as has Subversoin). 1.0
> has therefore very different dependencies (in terms of versions) than
> 1.4.
Is it worth having the dependencies in the Subversion repository as
vendor branches? At the risk of heresy, ClearCase UCM "composite
baselines" are extraordinarily good for just this kind of task. (I think
with SVN this would have to be handled with the appropriate copy and
merge from various vendor branches into a SVN release branch.)
Admittedly there is non-trivial overhead in managing vendor drops, but
in concept it allows someone to export /tags/<ver>, type "make", and
have a product.
--
----------------------
Mark S. Reibert, Ph.D.
svn@reibert.com
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 5 10:35:20 2007