[
https://issues.apache.org/jira/browse/SCM-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17960661#comment-17960661
]
ASF GitHub Bot commented on SCM-142:
------------------------------------
jira-importer commented on issue #444:
URL: https://github.com/apache/maven-scm/issues/444#issuecomment-2964594943
**[Bob
Herrmann](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=b...@jadn.com)**
commented
The output of bco is different enough that it doesnt detect file changes.
So the "stcmd" to "bco" thing is only really useful if you only always force
builds (and don't mind that it always says No Changes.)
I'm experimenting some more, trying to get this stuff to work correctly.
Will keep this bug advised of developements
> Starteam tree stale
> -------------------
>
> Key: SCM-142
> URL: https://issues.apache.org/jira/browse/SCM-142
> Project: Maven SCM (Moved to GitHub Issues)
> Issue Type: Bug
> Components: maven-scm-provider-starteam
> Environment: continuum-1.0.2
> Reporter: Bob Herrmann
> Priority: Major
>
> It only takes a few changes to starteam for the checked out filesystem to
> become hopelessly stale. The only recovery option is to completely remove
> all files and startover. Either the code checking out is not handing the
> timestamps correctly, or starteam command line has problems keeping a checked
> out tree in sync (this more likely - as we also see this problem with AntHill
> when using it's incremental builder.) Possible fixes might be to detect
> 'unknown' status's and flush the checked out tree. Or try using the 2005 bco
> command instead of stcmd.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
