[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: best practices for binaries/build results?

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 25 Mar 2008 14:01:09 -0500

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

> 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
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-25 19:58:06 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.