Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: StarTeam checkout task change
Date: Fri, 17 Jun 2005 10:17:33 -0400
Message-ID: 
 <4C23D8CA64819D44BF3F8134E0CF0E650759286E@CHAPDMSXMB04.ad.tiaa-cref.org>
Thread-Topic: StarTeam checkout task change
Thread-Index: AcVtb1NCkAd1IoFXQ/a+jog0yu0Z0wF12kIA
From: "Burgess, Benjamin" <BBurgess@tiaa-cref.org>
To: "Ant Users List" <user@ant.apache.org>
Cc: <scohen@javactivity.org>

I am willing and able to help with the StarTeam tasks (just got company
permission).  I did a search and found 13 open bugs/enhancements for
these tasks.  I have access to a license and server and am very familiar
with StarTeam SDK programming.  Perhaps I should contact you (or you me)
off list to better understand the process of contributing to Ant.

Ben Burgess
TIAA-CREF

-----Original Message-----
From: Steve Cohen [mailto:scohen@javactivity.org]=20
Sent: Thursday, June 09, 2005 11:48 PM
To: Ant Users List
Subject: Re: StarTeam checkout task change

Burgess, Benjamin wrote:
> Currently the StarTeam Checkout Ant task has an attribute named
"forced"
> with the description:
>=20
> =20
>=20
> If true, checkouts will occur regardless of the status that StarTeam
is
> maintaining for the file. If false, status will be used to determine
> which files to check out. Defaults to "false".
>=20
> =20
>=20
> When false, the task uses status to determine which files should be
> checked out.  This is currently implemented so that OUTOFDATE and
> MISSING are the only statuses where a checkout does occur.  If it is
> MERGE, UNKNOWN, MODIFIED, or of course CURRENT, it does not checkout
the
> file.
>=20
> =20
>=20
> This is not optimal behavior for an automated process such as part of
a
> continual build process (which I believe is where this target is
mostly
> used).  For automated processes, what is intended is that the checkout
> will leave the local folder exactly as the repository (checkouts would
> occur for MERGE, UNKNOWN, and MODIFIED as well as OUTOFDATE and
> MISSING).  Because the current task is not implemented like this, I
> wonder if most script users are left using forced=3D"true" which causes
> CURRENT files to be checked out needlessly, significantly increasing
the
> build time.
>=20
> =20
>=20
> What is the best way to fix this problem?  Change the behavior of
> checkout when forced=3D"false" to perform checkouts on the above
mentioned
> statuses?  Change the behavior of forced=3D"true" to skip CURRENT files
> (as I think this may always be unnecessary)?  Or perhaps add a new
> attribute called sync (or whatever) that overrides the forced
attribute
> and performs the checkout as described above?
>=20
> =20
>=20
> Please respond if one of the proposed changes would affect your build
> scripts (positively or negatively) in order to find the best solution
> for current ant users.  Also, perhaps this should be forwarded to the
> development list, especially if this thread becomes more code related.
>=20
> =20
>=20
> Ben Burgess
>=20
> TIAA-CREF
>=20
>=20
Hmm.  I wrote most of the StarTeam task code and maintained it.  I=20
stopped doing so about two years ago when I lost my job with the company

that had a license for StarTeam, and I've had nothing to do with with=20
StarTeam or the task since then.  I don't believe that there has been=20
any significant maintenance on the task since then.

I do remember the code you mention, and a quick scan of it brought more=20
of it back to mind.  I believe "Forced" is a concept that comes out of=20
StarTeam itself, corresponding to something that is available through=20
the StarTeam GUI or CLI.

I gather that you want something like FORCED checkouts unless the file=20
is exactly CURRENT.  The problem is that this is not possible using the=20
existing boolean definition of FORCED.

Changing this will require a rewrite of the logic of the task.  Can you=20
define a hierarchy of statuses?  For example are there ever occasions=20
when you would want to check out items with MERGE status but not=20
OUTOFDATE.  Is it a hierarchy or is it a mix and match set of=20
scenarios., that is can you place the statuses A,B,C,D,E,F such that if=20
you want D you also want E and F, and if you want B, you also want C, D,

E, and F?  If you find that that's logical, that might be a good way to=20
organize it.  If not, then you may have to define individual attributes=20
for each status that don't include any others.

Please notice that I used the pronoun "you".  This is quite deliberate.=20
  I cannot maintain the task anymore since I lack the ability to test=20
any changes and lack the need for the task that originally drove me to=20
become an Ant contributor and eventually a committer.

Ant always needs volunteers.  You sound like you have some good ideas.=20
Please consider making contributions to maintain this task if you want=20
it to grow and thrive.  You may find it enjoyable, and I'm still around=20
as a reference for you if you decide to do so.

Good luck!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


**************************************************************
This message, including any attachments, contains confidential information =
intended for a specific individual and purpose, and is protected by law.  I=
f you are not the intended recipient, please contact sender immediately by =
reply e-mail and destroy all copies.  You are hereby notified that any disc=
losure, copying, or distribution of this message, or the taking of any acti=
on based on it, is strictly prohibited.
TIAA-CREF
**************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org