[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: Reedick, Andrew <jr9445_at_ATT.COM>
Date: Tue, 25 Mar 2008 13:21:38 -0500

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Tuesday, March 25, 2008 2:04 PM
> To: users_at_subversion.tigris.org
> Subject: best practices for binaries/build results?
>
> 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.

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. 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. More importantly, 'rm' is implemented,
whereas 'svn obliterate' isn't.

 Re-cap: make sure the binaries (or build workspaces) are in a locked
down location (permission and ownership,) name the tar/dir to match the
svn tag, record which binaries/workspaces are the important ones (you
can delete the built-but-never-deployed binaries immediately,) and as
long as the build is repeatable and the source code tagged, you
shouldn't even have to worry about accidental deletions.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---------------------------------------------------------------------
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:22:21 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.