我正在使用Rational Team Concert（RTC）IDE和Jazz构建引擎为Spring Roo应用程序建立持续集成构建过程。设置构建定义时，Jazz Source Control选项卡上的Build Workspace字段允许选择用户的存储库工作空间或流。Jazz SCM持续集成 - 构建流与工作区？
RTC Continuous Integration Best Practices和其他Jazz构建资源一致指使用与构建用户关联的专用存储库工作空间，这使我相信这是首选方法。我无法直接找到有关从流中构建的任何信息。我们的项目流包含构建所需的所有工件，并且我已经测试并确认持续集成构建可以从流中工作。我无法想出为什么我需要为此创建和管理特定的工作空间。
我的问题是，我是通过直接从流中建立起来玩火吗？这种方法有没有潜在的下游并发症，我不知道？
回答我自己的问题，以防万一另一个SO用户将来遇到同样的问题。
经过一番实验后，我发现直接从流构建的一个缺点是它忽略了“Jazz Source Control”选项卡上的“仅在有可接受更改时才构建”属性。因此，只能在预定义的时间间隔内完成流的构建 - 无法将构建配置为仅在新的更改提交到流时才会发生。
构建需要专门的工作空间来接受来自流的新更改并使用它们来触发构建请求。
这里还有一个很大的区别。它与构建如何完成有关。让我强调一下这里的区别。
如果您从专用的构建存储库工作空间构建，那么您的构建工作空间已经包含了所有代码的副本。当您提交更改并构建开始时，只需更新已更改的文件（更改集），并将其从存储库物理复制到构建存储库工作空间。由于大多数更改都很小，因此需要从存储库中将代码库的0.1％到2％的任何位置进行复制。
如果你从“流”构建，那么你的构建工作区需要被创建（你必须在某处编译！）。所以当创建它时，需要更新ENTIRE代码库并将其从存储库物理复制到构建存储库工作空间。这意味着从存储库中获取100％的代码库。
每个文件操作都涉及一个调用来发现所需的资源，从托管存储库的数据库中获取此资源，然后让Jazz应用程序通过网络提供此源文件。它会导致数据库服务器，Web服务器和应用程序服务器上的负载。您下载的内容越多，这些组件所承受的负载就越多。
您可以使用一些方法将Jazz基础结构上的负载降到最低。使用内容缓存代理（使用简单的Squid代理服务器）可以提供帮助。
有关您的选项的更多详细信息以及这些选项的相对优点，请阅读我的博客文章和关于爵士乐性能问题的白皮书（http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a-guide-to-better-performance/）。那篇文章现在已经快一岁了，但仍然有效。您还可以查看Jazz部署Wiki（https://jazz.net/wiki/bin/view/Deployment/WebHome），并查看有关性能故障排除和性能问题的部分。