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:[EMAIL PROTECTED] 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: > > > > 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 > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ************************************************************** 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 ************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
