如何开发一个陷阱测试和性能测试来合并不同源代码控制系统下的文件？
在我工作的地方，我们已经使用 Subversion 多年了（显然，我来这里的时间不长）。这里有些人喜欢使用 TFS，有些人喜欢迁移到 Mercurial，还有一些人喜欢保持现状。由于 Visual Studio 集成不佳，其他源控件（Git、其他）无法运行。
新的源代码控制会减弱的最大问题/恐惧是对分支/合并的恐惧。
我想构建一个测试来直接确定哪个源代码控制更适合合并两个分支。考虑到可能没有 TFS 的“演示”版本，这可能会很困难。不过，这似乎是一个有趣的问题。
为了测试这一点，我需要了解以下内容：
- 合并算法通常不擅长什么？
- 我可以找到有关源代码控制系统使用的合并算法（特别是 TFS）的信息吗？
- 我能想出一种合并算法相对于另一种合并算法有什么优势吗？
- 大多数 VCS 在处理哪些类型的文件时会遇到问题？
更重要的是，你们中有人知道有人已经这样做了吗？
Where I work, we've been using Subversion for years (apparently, I've not been here that long). There's some people here who'd prefer to use TFS, some who'd prefer to migrate to Mercurial and some who'd prefer to keep status quo. Other source controls (Git, others) won't fly because of poor Visual Studio integration.
The biggest issue/fear that a new source control would attenuate is fear of branching / merging.
I'd like to build a test that directly addresses which source control is better at merging two branches. Considering there probably isn't a "demo" version of TFS, it might be difficult. Still, it seems like an interesting problem.
To test this I'd need to know the following:
- What is a merge algorithm typically bad at?
- Can I find information on what merge algorithm a source control system uses (specifically TFS)?
- Can I come up with any advantages that one merge algo would have over another?
- What types of files do most VCS have trouble with?
More importantly, are any of you aware of someone who has already done this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
关于 TFS，您有一个小的分支和合并入门< /a>，这可能没有考虑到 分支机构通过TFS2010成为一等公民。
您可以在此 合并：hg/git 与 svn 问题（最初关于 Git，但可以推广到其他 VCS）：任何类型的 十字交叉合并通常很难正确处理。
从那里，您还可以参考：
大多数 VCS 不会合并二进制元素（除了一些类似 word 文档的元素）。
Regarding TFS, you have a small Branching and Merging Primer, which may not take into acount the fact that branches became first-class citizen with TFS2010.
You can see problematic merges in this Merging: hg/git vs. svn question (about Git initially, but can be generalized to other VCS): any kind of criss-cross merging is generally difficult to handle properly.
From there, you can also refer to:
Most VCS won't merge binary elements (except some like word documents).
我不确定您是否会在不同工具的性能测试中找到很多用处。所有工具在可解析合并方面都很快。问题和比较点是它们导致冲突的频率。 TFS 2008 及之前的版本在解决冲突方面表现不佳。 2010 与我使用过的任何其他系统相当，包括 Git。您可能会在那里找到反对者，但他们想到的是 2008 年（诚然，他们在为您解决合并问题方面非常糟糕）。
关键是要经常推或拉。如果您分支，请确保经常从父分支拉取。离开的时间越长，发生冲突的机会就越大。对于生成的文件（例如 resx 文件和 .xxproj 文件）尤其如此。
I'm not sure you are going to find much use in a performance test for the different tools. All of the tools are fast with regards to resolvable merges. The problem and point of comparison is how often they result in conflicts. TFS 2008 and prior were terrible at resolving conflicts. 2010 is on par with any other system I've used, including Git. You may find ney-sayers there, but they are thinking of 2008 (admittedly very bad at resolving merges for you).
The key is to push or pull often. If you branch off, make sure you pull from the parent branch often. The longer you are away, the more chances for conflicts. This is especially true of generated files such as resx files and .xxproj files.