StarTeam checkout task change

["Burgess, Benjamin" <BB...@tiaa-cref.org>]

Currently the StarTeam Checkout Ant task has an attribute named "forced"
with the description:

 

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

 

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.

 

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="true" which causes
CURRENT files to be checked out needlessly, significantly increasing the
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 mentioned
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 attribute
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

TIAA-CREF



**************************************************************
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.
TIAA-CREF
**************************************************************

Re: StarTeam checkout task change

[Steve Cohen <sc...@javactivity.org>]

Burgess, Benjamin wrote:
> Currently the StarTeam Checkout Ant task has an attribute named "forced"
> with the description:
> 
>  
> 
> 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".
> 
>  
> 
> 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.
> 
>  
> 
> 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="true" which causes
> CURRENT files to be checked out needlessly, significantly increasing the
> 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 mentioned
> 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 attribute
> 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
> 
> TIAA-CREF
> 
> 
> 
> **************************************************************
> 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.
> TIAA-CREF
> **************************************************************
> 
> 
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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org