哪个源代码控制范例和解决方案嵌入自定义编辑器应用程序？

Question

我正在构建一个管理多个自定义对象的应用程序，这些对象可以由多个用户同时编辑（使用应用程序的不同实例）。这些对象有一个底层的序列化表示，我的计划是将它们（通过我的应用程序UI）保存在外部源代码控制系统中。当然这意味着我的应用程序可以检查对象的当前版本是否有更新，每个对象的合并接口等等。

我的问题是支持的源代码控制范例和特定解决方案以及原因。我（或许是天真地）看待源控制世界的方式是三种一般范例：

1. 单存储库，锁定访问（MS SourceSafe）
2. 单存储库，并发访问（CVS / SVN）
3. 分布式（Mercurial，Git）

我没有听说有人使用过＃多年，所以我打算完全忽视这个案子（除非我得到一个令人信服的论点）。但是，我不知道是支持＃2还是＃3，以及哪些具体实现。我担心使用范例略有不同，以至于我无法在单个UI中充分捕获基本操作。

我应该传达的最后一点信息是，该应用程序旨在部署在商业环境中，其中源控制系统可能已在使用中。我宁愿不支持多个解决方案，除非它真的是一个交易破坏者，因此在公司环境中广泛采用是一个优势。

更新： 我特意寻找一些推理：

1. 哪种范式有意义，因为它在商业上被接受了？ （我认为这个问题已由@Andrew Colson回答，但其他人的经历可能会有所不同）
2. 合理的假设是，平均商业开发商店更愿意使用现有的源代码控制系统，而不是为我的应用程序维护第二个（考虑到我的应用程序满足了与正常开发流程分开的非平凡需求） ）？
3. 根据我的需要，我是否认为＃2和＃3无法合理地捕获到一组操作中，而不会扭曲其中一种范式？
4. 对于您认为我应该使用的范例，您认为哪些具体实施对支持至关重要？

Answer 1

如果你想获得广泛的商业支持，你现在看起来比＃3更多＃2（或者甚至可能是＃1 ..）。

编辑： 当然，这取决于你对“商业”的意思，但大型商业组织往往在开发人员工具中处于落后状态。我主要看过SCM-per-project / group，但我确信技术含量较低的商业组织可能只使用他们IT团队提供的单一SCM解决方案。

Answer 2