我们在StarTeam服务器上使用CruiseControl，但StarTeam服务器出现崩溃问题。我们想知道我们是不是对服务器的打击太大了。在3台CruiseControl机器和总共约30个项目中，我们每分钟左右都会登录StarTeam并检查修改情况。我们的大多数项目中都有约20000个文件。有人有StarTeam在这种情况下的性能限制经验吗？
我还对CruiseControl与其他版本控制系统（如TFS、Perforce、SVN等）的性能指标感兴趣。在使用CruiseControl和大量文件项目时，它们是否存在可扩展性问题？
我在使用Star Team进行持续集成方面有一些经验，尽管使用的是TeamCity，而不是CruiseControl。在我们的案例中，从TeamCity到StarTeam的定期连接在我们的性能监控中几乎没有出现。
你看过你服务器上的星际团队日志文件了吗？-通常位于代码库或配置单元的根目录中。我通常发现日志足以解决任何问题。
您需要研究使用此处所述的"复合修改集"：
- 务实型项目自动化第69页
- http://www.nabble.com/How-I-can-use-compound-modification-set-with-triggers--td19397718.html
- http://cruisecontrol.sourceforge.net/main/configxml.html#compound
星际团队支持"触发器"吗？与其让CruiseControl机器每分钟检查一次存储库中的更改，不如让StarTeam机器通过触摸文件让CruiseControl知道代码何时更改。
基本上，当对项目进行更新时，VCS会接触到CruiseControl监控的文件（如project-a-update.txt）。一旦它注意到文件发生了更改，CruiseControl就知道要麻烦从VCS进行更新。因此，它每N分钟轮询一个项目的单个文本文件，而不是整个存储库。
在多个活动项目上运行CC时，我们最大的性能改进是在同一台机器上安装MPX缓存代理，并确保它存储文件属性和内容。（好吧，这一点，并确保在构建中使用ccache。）
StarTeam SDK中存在触发器的概念，但我不确定它与CC的集成程度。为了检查是否需要构建，我们将服务器的最后一个pull保存在一个干净的目录中，并使用stcmd列表来比较更改。这是非常迅速的。
据我所知，StarTeam不支持触发器。CruiseControl.NET StarTeam任务只支持轮询，我在任何地方都没有看到任何证据表明StarTeam本机支持触发器。
我正经历着完全相同的问题，尽管将星际团队推向极限。我不确定，但我开始认为崩溃问题与同时访问有关，因为当开发人员和CruiseControl高度活跃的项目时，问题会更频繁地发生。
对变革进行民意调查的惩罚也越来越大。更糟糕的是，处罚增加了一倍。对StarTeam的第一个调用是调用"hist"以获取用于报告和触发构建的变更集，然后调用"co"对整个源树进行第二次检查，并检查出任何过期或丢失的文件。如果有人能提出一种围绕StarTeam项目创建触发器的方法，可以消除其中任何一个，我很乐意尝试一下。
我能找到的额外信息。
StarTeam并不总是断开用户（或CruiseControl访问情况下的代理）的连接，并且可能导致同一用户/代理有数十个打开的连接/登录。不幸的是，很难确认这是否是一个相关的问题，因为我无法可靠地超载服务器。
我们使用的是没有MPX的旧版本的StarTeam。我想知道是否有人在支持MPX方法的不同连续集成环境中使用StarTeam的经验。
首先，我没有星际团队的经验！不过，我确实有CruiseControl和颠覆的经验。
你可以把你的时间表间隔改为不那么激进的1分钟——3-5分钟通常可以用来检查项目是否需要建设。但我承认，你需要经常检查可能是有原因的。
Subversion的伸缩性非常好。这是因为每当cruise检查是否有更新时，它所做的只是将项目的本地版本号与远程版本号进行比较，而不需要检查每个文件。因此，此检查的速度不受项目中文件数量的影响。
我希望这对你有帮助。