philosophical question

[Shawn Castrianni <Sh...@halliburton.com>]

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.

Re: philosophical question

[John Gill <ll...@gmail.com>]

Really, they want to use complex clearcase config specs to control
dependencies??? Where I used to work they used to do that, and it was a
complete mess. The config specs became so complex, that it was almost
impossible to build anything unless you were the total expert with that
package. And if you wanted to reproduce a build months later, then good luck
with that.

The solution was not to use ivy, but to at least keep releases in a separate
release area (yes a "versioned" file system, with each version as a
directory).

Negatives for ClearCase idea:
ClearCase is slow with complex config specs (are you using dynamic or
snapshot views?)
Setting up config specs is complex. Are people expected to type them in all
the time?
So how are you going to maintain all these config specs? Are going to have
to be stored somewhere? Are they suggesting that they check those in as
well?
I believe that ClearCase doesn't do diffs for binaries (but I could be
wrong), so they wont actually save that much space. You could use ivysvn
(subversion does do diffs for binaries and will save space).
Are they really that hard up for disk space? If they can afford ClearCase,
surely they can afford another disk drive.

Positives for ivy (other people are probably better at highlighting the
benifits of ivy better than I am so I an just going to focus on the
advantages as I see them over the ClearCase idea):
ivy.xml can be checked into clearcase and labeled with your code. All you
need access to is the source, and the shared filesystem where the releases
are (which the ivysettings.xml points to).
It is simple to compare releases (use something like beyondcompare if you
have it) and you can see what the differences between releases are. The
clearcase way would require you to set up two views and compare them.
You just need a clearcase view on the source code you are working on.


Other points:
You should always keep it simple, and ensure that all the files you need for
your build are under one root directory, and that there are no file not
related to the build in there either. This keeps it very clean, and when you
label your code, ensure you label every file and directory from the root of
your project down, and all directories above it. Then you can have a view
which says "element * myproject-1.2.3" and you will see exactly what was
used to do your release.


Frankly, having worked somewhere where they tried the ClearCase idea, I
would not work somewhere again that did it like that, and that alone is a
ClearCase for doing it a different way :-)

On Sat, Feb 23, 2008 at 1:26 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

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




-- 
Regards,
John Gill

Re: philosophical question

[Xavier Hanin <xa...@gmail.com>]

John already made a very good case for Ivy, so I don't have much to add. I
don't have any experience with trying to use ClearCase to do dependency
management, but I understand CM people having trouble to understand the
exact role of Ivy, since it's a kind of versionning system, and in some
cases you may wonder which versionning system to use (I recall a company who
where using Ivy to bootstrap their build, this could have been done with a
SCM too).

IMO Ivy shines in transitive dependency management, and this is a domain not
addressed by a SCM AFAIK. Dealing with conflicts in large dependency graphs
with different version constraints is not easy, and having a tool helping in
this area can really make the difference in day to day work with the system.

Ivy flexibility can also be used to cleanly handle some special cases. I
know developers who setup a simple shared directory on their box as Ivy
repository, so that other team members can easily try their own build of a
module without having to push it in the SCM. Sometimes CM people don't like
this kind of thing, but if you add proper tooling for it with appropriate
checks to make sure people don't push changes to the SCM when they are using
a private build, you can win some flexibility and it's cleaner than sending
jars by e-mail.

Xavier

On Sat, Feb 23, 2008 at 5:26 AM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> wrote:

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




-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: philosophical question

[Gilles Scokart <gs...@gmail.com>]

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 <Sh...@halliburton.com>:
>
> 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