目前（2011年）什么是只有一个位置的公司的推荐源代码存储库。
分布式存储库很难处理，因为签入和签入有两个步骤。每个系统上都有一个完整的存储库副本。这是约。使用我们当前的系统50 GB。如果您想要结帐新系统，这会消耗很多时间。没有本地系统的备份。等
目前我们使用subversion。但颠覆在合并方面存在很大问题。
Eclipse插件非常好用，因为这是我们使用过的IDE。
地平线上是否有新星？
答案 0 :(得分：3)
目前（2011年）什么是只有一个位置的公司的推荐源代码存储库。
Git或Mercurial。
分布式存储库很难处理，因为签入和签入有两个步骤。
听起来像你认为DVCS是“颠覆但分布式”。他们并非如此，并且想到这些就会让你错过他们的优势。
为DVCS提交没有两个步骤。使用Git（stage，then commmit）提交有两个步骤，但这是Git功能，而不是DVCS功能。
我认为（请纠正我，如果我错了）你认为这两个步骤是提交（本地）和推送（到中央存储库） 。如果您希望每个开发人员所做的每一项更改都能立即供其他人使用，您只需要这样做。
使用简单不可避免的集中式系统（即SVN）。使用DVCS，您可以使用提交作为备份点而不是发布。
不同之处在于，在SVN中，您无法承担不完整的代码，因为它会影响整个团队（您可以这样做，直到您修复它，团队中没有人会有可用的代码）。在DVCS中，您可以根据需要（本地）提交（和合并），只有在有稳定的东西时才进行同步。一旦你习惯了它，“SVN方式”看起来就是不必要的限制。
我们使用DVCS的方式如下：我们（大约8名开发人员）有一个中央存储库，每个内部存储库在每次内部发布之前（到测试团队）进行同步。我们每个人都会在构建之前同步它们的源（从服务器拉出更改，合并，拉动）。然后，我们中的一个人将在服务器机器上进行构建。
我们很多时候会有两位同事在新功能的两个方面工作，并且只在我们自己之间同步beta代码。当我们有稳定的东西时，我们会把它放在服务器上。与此同时，其他开发人员不必看到不完整或破坏的代码，并且中央代码库保持稳定，而我们仍然可以承诺并获得源代码控制的全部好处。
每个系统都有一个完整的存储库副本。
这很好。这意味着，通过创建本地存储库，您可以获得100％的完全冗余，并且可以有效地消除服务器单一故障点。如果您的服务器硬盘崩溃，您只需将其中一个开发人员的本地存储库克隆到新的服务器硬盘。
这是约。使用我们当前的系统50 GB。
但是每个客户端只能同步一次。在初始同步之后，所有后续的都是增量的。
你可能会感到惊讶。 Hg和Git都在传输之前压缩数据（我不确定SVN是否这样做）并且它们也压缩存储库本身。考虑到这些系统存储更改而不是文件（即更改增量，而不是完整文件），使用DVCS的存储库可能比使用SVN时更小。如果您想要结帐新系统，这会消耗很多时间。
缺点（如果您考虑冗余和备份问题，您可以读到“上行”）是您在每个克隆过程中本地复制完整存储库。
没有本地系统的备份。
没有必要 - 备份DVCS存储库通常不是问题。每个本地系统都是中央存储库的完整副本（包含完整历史记录），中央存储库是每个客户端存储库的完整备份（在每次推/拉时同步）。
使用一个中央存储库和一个开发人员，您可以获得100 + 100％的冗余。有两个开发人员，100 + 200％冗余。
它并不比这更安全。
目前我们使用subversion。但颠覆在合并方面存在很大问题。
关于合并，颠覆被设计破坏，因为SVN不存储任何元数据来决定如何合并（因为SVN跟踪文件，而不是更改）。当SVN合并时，它会尝试进行有根据的猜测，这在很简单的情况下是可以的。对于非平凡的情况，当你的工具/计算机应该这样做时，你最终会尝试手动解决一个复杂的（人类）问题。
答案 1 :(得分：1)
作为I just documented，Eclipse插件中的新星是...... DVCS（Git到 EGit ）。
虽然它可能不是你想要的，但我仍然指出它是Eclipse上当前的“新星”，因为所有Eclipse项目现在都在Git repos上，而Eclipse致力于为Git工具提供良好的支持。
然而，这包括许多挑战，因为我将这个新的VCS放在我的企业环境中，如下所示：
“Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?”