ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Kilian <>
Subject Re: published module storage
Date Tue, 12 Feb 2008 06:50:53 GMT
On Mon, Feb 11, 2008 at 11:49:29PM -0600, 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.

IMHO, binaries don't belong into an *S*CM. And for binary diffs, I
don't think you'll save much disk space, unless most of the .class
files included in different versions of you artifacts (assuming
.jar files) don't change at all between builds. Worse, if you artifacts
are .tar.gz files, or if they are .war or .ear files containing
freshly built .jar files, there'll be almost no block of data common
to the previously built version.

> 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?

Keep the complete modules in the ivy repository; disk space is cheap
these days. In addition, check in and tag the delivered ivy file
of a project whenever you run a release build (to be sure you *can*
rebuild everything from scratch should your ivy repository ever get

If you've one single ivy repository (i.e. not several separate
repositories for different developement groups depending on each
other), it may be feasible to scan the repository every now and
then and search for old versions of modules not used by any other
module and delete the unused versions.


GDB has a 'break' feature; why doesn't it have 'fix' too?

View raw message