ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: philosophical question
Date Mon, 25 Feb 2008 12:34:55 GMT
Did their scm based solution tell why a library is required when there is
dependencies of dependencies?  Did their solution will help to identify that
2 modules have conflicting dependencies?  Did their solution manage
different type of dependencies (compile, runtime, test, ...) without some
+/- important duplication of the info in build script, scm content or other

That's what a dependency managment tool does.  I think the SCM solution they
want is just a solution to store dependency in a versioned way.  It is not a
solution to manage them (=change & control the changes).

2008/2/23, Shawn Castrianni <>:
> I am trying to defend the use of IVY in my company and some CM team
> members are suggesting we use an SCM system to manage our
> dependencies.  They feel that IVY is trying to reinvent the wheel by acting
> like a versioned filesystem.  They say why not just check in all builds into
> an SCM like Clearcase.  Then the dependencies that you pick up can be
> controlled by the Clearcase config spec or view in other SCM tools.  You can
> label/tag the versions to handle build promotion status and other
> scenarios.  Another advantage is that you only have to check in what has
> changed.  With IVY, each new published module could contain nothing new
> versus the previous version but still takes up the same amount of
> space.  With an SCM tool that checks for actual differences before
> committing, would only check in the changed files.  The labels/tags would
> then be placed on some new file versions that did change and some old file
> versions that didn't change.
> Can people help me persuade my fellow CM team members why IVY is
> better?  They make a good case with their arguments.  Is there some
> showstopper scenario that an SCM tool can't handle that IVY can?
> ---
> Shawn Castrianni
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly
> prohibited.  If you are not the intended recipient (or authorized to receive
> information for the intended recipient), please contact the sender by reply
> e-mail and delete all copies of this message.

Gilles Scokart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message