Re: best practices for binaries/build results?

Reedick, Andrew wrote:

>> Is there an established procedure or recommendation for storing
>> versioned binaries and build by-products. I don't really want them
>> pushed back to the source repository because they are mostly
>> reproducible, have a short useful life, and are too big to let them
>> accumulate forever. Are there any common conventions that people use
>> to
>> consistently tie the results that need to go through testing and
>> possibly production to the tag/revision that generated them in a way
>> that works across different projects? Or would it be a good idea to
>> push them into a separate repository that could be managed differently
>> using some convention for tag names to tie them together?
>>
>
> Keep the workspace used for that build around for a while. Make sure
> it's set read-only and owned by a special user after the build. Simple,
> lazy, and can be deleted easily when it's no longer of value.
>
> If you assemble the components into a tar as part of a distribution
> package, just keep the tar in a locked down directory.

Thanks - that may be good enough.

> I don't think I would mess with a special binary only repository.
> You're not actually versioning the binaries, so you would only need
> subversion for its ability to lock-down the files and act as a holding
> area.

There are still some things where the concept of versioning still
applies. I'd like to be able to track things through testing and
production rollout by a tag or revision - but they shouldn't be changing
then.

> The file system should be adequate, since you can lock down the
> directories/files. Plus, you can 'tag' a tar file via it's filename, or
> by the directory it's stored in.

I was thinking that it might be handy to use svn as a transport service
that would be easy to invoke to grab any specific tag name with a check
out or export that would bring along any tools needed for an automated
install, but I guess that would be just as easy with file shares or a
web/ftp server.

> More importantly, 'rm' is implemented,
> whereas 'svn obliterate' isn't.

Which is the real reason for even asking this question... With svn, I'd
have to periodically dump/filter/load or have a rolling set of
repositories so old versions could be deleted. It's probably not worth
it just to get a commit log.

-- 
    Les Mikesell
     lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org