ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Nesbitt <stephen_nesb...@alumni.cmc.edu>
Subject Re: published module storage
Date Tue, 12 Feb 2008 17:43:51 GMT
On Monday 11 February 2008 09:49:29 pm Shawn Castrianni wrote:
> We have a debate going on about where to store our published modules.  Some
> say it should be on a filesystem so that we can delete older builds to
> reclaim disk space since we should always be able to repeat a build from
> the past if needed.  Some say they all should be checked into an SCM
> repository so that we can easily get old dependencies when repeating a
> build and since some SCM repos like subversion stores binaries as diff,
> saving disk space.
By "published" do you mean "formally released". If so my preference would be - 
in contrast to Matthias - to put them in the SCM system. My reasons for doing 
is the assumption that releases are relatively infrequent and therefore 
important to retain for a relatively long period of time. Storing them in the 
SCM allows one to associate metadata with them, provides ready access to any 
machine or user who has access to the SCM (no need to maintain a separate 
repository) and is likely to be backed up.

Both options are valid. I just prefer the consistency and power of placing 
them in the SCM. 
>
> At first I was in favor of option 1, but I am starting to lean towards
> option 2.  If I want to repeat a build from 2 years ago, I don't want to
> have to repeat all of its dependent builds as well since those would most
> likely be deleted from the file server.  With everything checked into an
> SCM tool, I can always retrieve any past dependent build to be used a
> dependency to repeat an old build.  However, how would I configure ivy to
> get dependencies from an SCM repo?  I don't want to have to implement my
> own resolver.   What do other people do to be able to support rebuilding
> something from the past with dependencies?
I'm not a huge fan of depending on rebuilds to recreate important releases. 
There is too much that can go wrong, too many dependencies that are known but 
not readily available on a build machine (db version, etc.), and too much 
time and effort involved.

-steve
CM Architect <former>

Mime
View raw message