ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Burgess, Benjamin" <>
Subject RE: StarTeam checkout task change
Date Fri, 17 Jun 2005 14:17:33 GMT
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

-----Original Message-----
From: Steve Cohen [] 
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
> with the description:
> If true, checkouts will occur regardless of the status that StarTeam
> maintaining for the file. If false, status will be used to determine
> which files to check out. Defaults to "false".
> 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
> file.
> This is not optimal behavior for an automated process such as part of
> continual build process (which I believe is where this target is
> 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="true" which causes
> CURRENT files to be checked out needlessly, significantly increasing
> build time.
> What is the best way to fix this problem?  Change the behavior of
> checkout when forced="false" to perform checkouts on the above
> statuses?  Change the behavior of forced="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
> and performs the checkout as described above?
> 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.
> Ben Burgess
Hmm.  I wrote most of the StarTeam task code and maintained it.  I 
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 
StarTeam or the task since then.  I don't believe that there has been 
any significant maintenance on the task since then.

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

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

Changing this will require a rewrite of the logic of the task.  Can you 
define a hierarchy of statuses?  For example are there ever occasions 
when you would want to check out items with MERGE status but not 
OUTOFDATE.  Is it a hierarchy or is it a mix and match set of 
scenarios., that is can you place the statuses A,B,C,D,E,F such that if 
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 
organize it.  If not, then you may have to define individual attributes 
for each status that don't include any others.

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

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

Good luck!

To unsubscribe, e-mail:
For additional commands, e-mail:

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message