DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9849>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9849 stcheckin with rootlocalfolder set forces checkin [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2002-06-16 15:10 ------- After having looked into the matter, I remember the painful process by which I came to implement this task in this half-baked manner. Unfortunately, the functionality you wish for cannot be implemented given the tools we have to work with. In developing all of these StarTeam tasks we are constrained by what is available in the starteam sdk. Unfortunately in the starteam sdk, in the com.starbase.starteam.File class, there are two getStatus() methods. One takes no parameters and uses the file pointed to by the user-selected default path within the StarTeam GUI. This method has public access. Another, deeper method takes a an arbitrary java.io.File as a parameter and compute's that file's status, but this method does not have public access and therefore cannot be called by ant code. This is why the ant task will always compute status relative to the default file unless forced is set true to override the status check. I consider this a bug in the starteam sdk, but since this sdk is entirely undocumented, it is not clear what can be done about it, although there may be some way to do it that I have not been able to find. I considered a possible workaround from an ant perspctive that would use the <exec> task around a call to the stcmd executable which may somehow work around the problem. Unfortunately, looking at the source code for stcmd, it seems that here too, the status check around an arbitrary file is not implemented so I doubt this workaround would work, though you are welcome to try it and prove me wrong. If proven wrong, I will dig deeper into this. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
