2

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

我的问题是要支持什么源代码控制范例和具体解决方案以及为什么。我（也许是天真地）看待源代码控制世界的方式是三种通用范式：

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

我已经好几年没听说有人使用 #1 了，所以我打算完全不理会这个案例（除非我得到了令人信服的论点）。但是，我不知道是支持#2 还是#3，以及哪些具体实现。我担心使用范式存在细微差别，以至于我无法在单个 UI 中充分捕获基本操作。

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

更新：我专门寻找一些推理：

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

2 回答 2

2

如果您想要广泛的商业支持，那么您目前更多地关注#2 而不是#3（甚至可能是#1..）。

编辑：当然，这取决于您所说的“商业”是什么意思，但大型商业组织往往落后于开发人员工具。我主要看到的是每个项目/组的 SCM，但我确信技术含量较低的商业组织可能只使用其 IT 组提供的单个 SCM 解决方案。

于 2010-06-08T03:56:11.763 回答
2

#2 和/或 #3

#1单一存储库，锁定访问 - 现在很少使用，因此它们并不值得一提。

#2单一存储库、并发访问——被称为 VCS 或 CVCS（集中式版本控制系统）仍然被广泛使用。

#3分布式 - 是下一件大事，因为它们消除了其他系统强加给开发人员的许多人为障碍。

首先，回答您的问题/疑虑：

1.商业接受度取决于组织及其开发人员。如果经理是负责所使用软件的人，并且他们倾向于在几乎没有实际证据的情况下强硬保守的决定，那么他们可能会默认使用微软提供的任何东西。在这种情况下，祝你好运。我听说过的所有关于 MS 版本控制（特别是 SourceSafe）的事情都是坏事，我不确定 MS 是否有 DVCS 选项。

OTOH，如果开发人员团队负责选择他们的工具（或者经理们思想开放），​​那么 git 或 mercurial 可能是要走的路。git 很难适应，因为它过于复杂。mercurial 是 CVCS 的一个非常简单的过渡，请务必下载 tortoisehg GUI 客户端以了解工作流程。两者都完全稳定并可以投入生产。Mercurial 和 Subversion 用于 Sourceforge.net 以及 Google Code，它们都托管了数千个项目。他们可能有的任何错误，他们要么知道他们已经解决了。

2.我敢肯定，当我说“在这个时代，滚动你自己的版本控制系统是一种荒谬的时间和精力浪费”时，我代表了整个开发人员。

当然，您可能可以制作一个小型且适合您的应用程序的专用版本控制系统；但是，在您决定之前，请考虑一下这项工作所涉及的所有时间和精力。更不用说，您需要将版本控制系统的代码置于版本控制之下。纳夫说……

3.不，您不是，您实际上可以同时使用两者。很多人使用 CVCS（通常是颠覆）在组织范围内进行集中版本控制，同时使用 DVCS 在较小的小组或个人中进行本地开发（甚至有微软工程师在他们的开发人员小组中秘密使用 git 的故事）。由于 DVCS 在文件系统中仅由隐藏文件夹和可能的忽略文件表示，因此很容易将所有信息添加到 CVCS 忽略文件中，这样信息就不会在中央存储库中被跟踪。Easy peasy，如有必要，您可以利用两者的优势。

我认为，当您提交 DVCS 的提交历史记录到 CVCS 时，甚至有办法将其传输到 CVCS。虽然，我不知道具体是怎么做的，因为我从来没有理由这样做。

4.＃2和/或＃3绝对。

如果已经有一个 CVCS 并且你应该使用它，我会说两者。

Subversion 可能会做任何事情，但问题是，CVCS 的所有版本历史都保存在服务器上。IE，如果您没有直接的网络访问权限，则无法提交或更新。这对一些开发人员来说可能很好，但大多数开发人员都在移动，并且在他们需要工作时不能总是找到网络连接。不好的部分是提交被拖出，他们最终在与主干开发分支进一步不同步的源代码上工作。Subversion（或一般的 CVCS）在处理分支方面也是出了名的糟糕，这意味着，如果您有两个开发人员在主线的两个不同分支上测试想法并且他们决定将它们重新合并在一起，事情就会变得丑陋。DVCS 在分支机构中要好得多。

如果没有 CVCS，则仅使用 DCVCS。

DCVS 能够做任何事情，因为您可以将存储库的远程克隆用作存放点。工作流程的不同之处在于，当您提交到 CVCS 时，如果没有问题，它会直接进入远程存储库。在 DCVS 中，当您提交它时，如果没有更改，它会提交到本地存储库。然后，在您准备好发布一组更改后，您将提交（或在 mercurial 中同步）推送到远程。

由于 DCVS 中的存储库都是相同的，因此您可以从任何其他存储库推/拉，无论位置如何。一开始有点棘手，但它有一些明显的优势。首先，无论你走到哪里，你总是带着项目的历史，所以如果中央服务器出现故障，你所有的开发人员都带着它的备份副本，所以这没什么大不了的。其次，允许开发人员在任何时候不受限制地提交是非常有益的。开发人员提交的越多，版本历史记录就越详细，如果代码需要回滚，您发现问题的速度就越快。

实现您所描述的内容。在您希望放置的任何位置创建启动器存储库。它所需要的只是网络访问。

将初始文件复制到项目文件夹并提交。

让所有处理文件的人克隆他们自己的存储库副本。

如果您需要以编程方式进行更新，您可以检查是否需要从中央存储库中提取更改或提交并在必要时使用命令行推送新更改。

只要您可以将序列化数据写入源代码控制下文件夹中的文本文件，这不是问题。当您提交/推送时，您必须手动解决冲突，但这是任何版本控制系统所期望的。

如果要确保远程存储库和本地存储库之间几乎没有冲突或没有冲突，请始终在提交之前拉取本地副本。这样，如果有冲突，可以在本地处理。

这就是我得到的。

于 2010-06-11T02:31:53.890 回答