Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of llignhoj@gmail.com designates
 209.85.142.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=nsKKTSne1Zn07KSy+5TlDDI1D3QAqC6rGPhKQIt3+JeYJWsU3n/BjzwtoDSbd9VO9eQPA0x9U4ZRgSPvhqsgZaZZUBM5jRWC79IEcFcxvk2UziemRhXF2u6S0N8/CgZZJQaqL24nMPu/HCCcsK1AgN1ryMxrDenwGCdyJs0FdnE=
Message-ID: <49c77ae40802222101w384cfb54k779d5d3d4295008f@mail.gmail.com>
Date: Sat, 23 Feb 2008 14:01:22 +0900
From: "John Gill" <llignhoj@gmail.com>
To: ivy-user@ant.apache.org
Subject: Re: philosophical question
In-Reply-To: 
 <745B9EDF57802349B13F90E4E0B4B86C3B9F1D581B@HOUEXCH012.corp.halliburton.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2603_17215955.1203742882670"
References: 
 <745B9EDF57802349B13F90E4E0B4B86C3B9F1D581B@HOUEXCH012.corp.halliburton.com>

------=_Part_2603_17215955.1203742882670
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_2603_17215955.1203742882670--