At 2/18/2006 08:38 PM, eg wrote:
>I generally do not store ongoing binary builds in repositories.
>As part of a configuration management procedure you theoretically need to able
>to get back to any build at a previous timepoint (however infrequent).
>You can do this through a combination of careful tagging/labelling, build
>procedures, libraries and toolsets.
...which certainly needs to be done regardless.
I also like the benefit of being able to get back to the exact binary that
was built, in case the exact build environment could not have been easily
duplicated...
>Given that we do the above, simple archiving (outside of repository) of
>labelled
>copies of binary builds has sufficed for our needs. YMMV.
>
>If I did, I would consider using a separate repository.
...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.
-Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 19 06:02:43 2006