best practices for binaries/build results?

[Les Mikesell <le...@gmail.com>]

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?

-- 
   Les Mikesell
     lesmikesell@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: best practices for binaries/build results?

[Les Mikesell <le...@gmail.com>]

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@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: best practices for binaries/build results?

["Reedick, Andrew" <jr...@ATT.COM>]

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Tuesday, March 25, 2008 2:04 PM
> To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org