Matt England wrote:
>
> ...and a separate "build output" repo seems like the most attractive
> alternative at the moment. Alas, we still need to implement a better
> release-control (that includes more-detailed file naming of the output
> tarballs, rpms, and other packages) on top of the whatever mechanism
> we use to save/archive the release sets. I'm also looking for
> suggestions on methods/tools/paradigms for these processes, too. I've
> built and help built processes like these for other software projects,
> but I need to make more-robust things then I have in the past.
>
> I'm looking forward to more comments.
>
> I'm also interested to know if 'svn obliterate' may come to fruition
> in the near future, in the event we may want to "thoroughly clean"
> some files and their history from the existing repo; however, this is
> not a prime concern.
>
We are about to do this exact thing. We call it the "engineering
releases" repository. We won't put every build there, only builds that
need to be tested by the test group. We also will use it to store
outputs from the other groups that end up in the finished product, such
as finished documentation. A good document control system might be a
better solution, but this is what we have.
Our release repository is structured along the lines of
product/version/build. The build folder name is identical to the source
tag name. In the version folder, we also put output from other groups
such as documentation and on-line help files.
Once the test group approves a release, they copy the <build> folder to
'final'. For example, widget/2.0/2.0.0.7 gets copied to
widget/2.0/2.0-final. They then create the release notes and upload
those. The CM group creates the final package with the release notes,
on-line docs, etc. and uploads that to our PLM system in Oracle. We have
lots of different types of products, so the details are going to be
different for the different product types.
The advantage I see of using Subversion is that you have a central
mechanism to move files between different departments involved in the
final release. There's no more 'where's the build?', 'where do I put the
demoshield output?' type questions, no more huge email attachments, and
the security is better than using a shared file system.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 20 16:01:35 2006