将文件从一个 TFS 项目集合复制到另一个 TFS 项目集合
定期将 TFS 项目集合 A 中的项目中的一些文件复制到 TFS 项目集合 B 中的另一个项目的可靠方法是什么。将获取源中的最新数据并检查目标，覆盖冲突（如果有）。我已经自动化了 Team Foundation Build，并且可以在其中添加脚本或步骤。我希望它成为自动构建的一部分，但如果我必须每晚在固定时间运行它也很好。我只需要一种可靠且自动化的方式来做到这一点。
What would be a reliable way to copy some files from a project within TFS projects collection A to another project within TFS projects collection B regularly. The latest from source is to be taken and check into the destination, overriding conflicts (if any). I have automated Team Foundation Build and can add a script or step within it. I would prefer this to be a part of automated build but it would also be fine if I had to run it nightly at a fixed time. I just need a reliable and automated way to do it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能需要研究 Team Foundation Server 集成工具，它允许您在两个 TFS 服务器之间设置同步。您可以在两个服务器之间设置双向同步或单向同步 - 在您的情况下，听起来您希望在集合 A 和集合 B 之间进行单向同步。
我们已经使用双向同步大约一个月了，并且非常高兴与它。
You may want to investigate the Team Foundation Server Integration Tools, which allow you to set up synchronization between two TFS servers. You can set up either bidirectional synchronization or unidirectional synchronization between two servers - in your case, it sounds like you want unidirectional synchronization between collection A and collection B.
We've been using the bidirectional synchronization for about a month now and have been very pleased with it.
我认为您可能需要重新考虑该行动方针。 TPC 之间的边界应该是牢固的：它们应该是两个沙箱。您将源代码从一个沙箱移植到另一个沙箱的原因是什么（我假设这就是您的意思）？
如果您真正需要的是输出（假设您正在一个 TPC 中构建组件并需要在另一个 TPC 中使用它），那么也许您真正想做的是安排构建的项目该组件将输出（例如二进制文件）存储在可访问的网络放置位置，并让使用者（第二个 TPC 的开发人员和自动化构建）复制这些输出并将其添加为需要的引用。
这样，您就不会冒代码中出现太多冲突的风险，并且实际上可以促进更好的可重用性。
希望这有帮助，
阿萨夫
I think that you might want to reconsider that course of action. The boundary between TPCs is meant to be a strong one: they are supposed to be two sandboxes. What would be your reason to port source code (I'm assuming that this what you mean), from one sandbox to another?
If what you really need is the outputs (say you are building a component in one TPC and need to use it in another), then perhaps what you really want to do is to arrange for the project that builds the component to deposit the output (binaries, for example) in an accessible network drop location, and have the consumers (the second TPC's developers and automated builds) copy those and add them as references where needed.
This way you do not risk as many conflicts in the code, and actually promote better reusability.
Hope this helps,
Assaf