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 files.
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 <[EMAIL PROTECTED]>: > > 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
