什么是适合小公司的现代源代码存储库？
目前（2011 年）一家只有一个地点的公司的推荐源代码存储库是什么。
分布式存储库太困难了，因为有两个步骤来签出和签入。每个系统上都有存储库的完整副本。这大约是。我们当前的系统为 50 GB。如果您想签出新系统，这会花费很多时间。本地系统没有备份。目前
我们使用subversion。但 subversion 在合并方面存在很大的问题。
Eclipse 插件会非常好，因为这是我们使用的 IDE。
地平线上是否有新星出现？
What is currently (2011) the recommendation source code repository for a company with only one location.
The distributed repositories are to difficult because there are 2 steps to checkout and checkin. There is a completely copy of the repository on every system. This are approx. 50 GB with our current system. This consume many time if you want checkout a fresh system. There is no backup of the local systems. etc.
Currently we use subversion. But subversion has large problems with merging.
An Eclipse plugin will be very nice because this is our used IDE.
Is there any new star on the horizon?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Git 或 Mercurial。
在我看来，您将 DVCS 视为“颠覆但分布式”。但事实并非如此，这样思考会让你错过他们的优势。
DVCS 无需执行两个步骤。使用 Git 提交有两个步骤（阶段，然后提交），但这是 Git 功能，而不是 DVCS 功能。
我认为（如果我错了，请纠正我）您认为这两个步骤是提交（本地）和推送（到中央存储库）。仅当您希望每个开发人员所做的每项更改都能立即可供其他人使用时，您才需要这样做。
对于集中式系统（即 SVN），这是不可避免的。使用 DVCS，您可以使用提交作为备份点而不是发布。
不同之处在于，在 SVN 中，您不能提交不完整的代码，因为它会影响整个团队（您会这样做，并且在您修复它之前，团队中没有人会拥有可用的代码）。在 DVCS 中，您可以根据需要（本地）提交（和合并），并且仅在拥有稳定的内容时进行同步。一旦你习惯了它，“SVN 方式”就会显得有不必要的限制。
我们使用 DVCS 的方式如下：我们（大约 8 名开发人员）拥有一个中央存储库，该存储库每周在每次内部发布（向测试团队发布）之前进行同步。我们每个人都会在构建之前同步他们的源（从服务器拉取更改、合并、拉取）。然后，我们中的一个人将在服务器计算机上进行构建。
很多时候，我们会有两个同事在新功能的两侧工作，并且只在我们之间同步测试代码。当我们有稳定的东西时，我们会把它放在服务器上。与此同时，其他开发人员不必看到不完整或损坏的代码，并且中央代码库保持稳定，而我们仍然可以提交并充分享受源代码控制的好处。
这很好。这意味着通过创建本地存储库，您拥有100%的完全冗余，并且有效消除了服务器单一故障点。如果您的服务器硬盘崩溃，您只需将其中一位开发人员的本地存储库克隆到新的服务器硬盘即可。
但每个客户端只需同步一次。初始同步后，所有后续同步都是增量的。
你可能会感到惊讶。 Hg 和 Git 都会在传输之前压缩数据（我不确定 SVN 是否这样做），并且它们还会压缩存储库本身。考虑到这些系统存储更改而不是文件（即更改增量，而不是完整文件），使用 DVCS 时的存储库可能比使用 SVN 时更小。
缺点（如果您考虑冗余和备份问题，您可以读到“优点”）是您在每个克隆过程中在本地复制完整的存储库。
只是没有必要 - DVCS 存储库的备份通常不是问题。每个本地系统都是中央存储库的完整副本（包含完整历史记录），中央存储库是每个客户端存储库的完整备份（在每次推/拉时同步）。
通过一个中央存储库和一名开发人员，您将拥有 100+100% 的冗余。两名开发人员，100+200%冗余。
没有比这更安全的了。
关于合并，Subversion 在设计上被破坏了，因为 SVN 不存储任何元数据来决定如何合并（因为 SVN 跟踪文件，而不是更改）。当 SVN 合并时，它会尝试做出有根据的猜测，这在微不足道的情况下是可以的。对于重要的情况，当您的工具/计算机应该这样做时，您最终会尝试手动解决复杂的（对人类而言）问题。
Git or Mercurial.
Sounds to me like you see DVCSes as "Subversion but distributed". They are not so and thinking about them like that will make you miss their advantages.
There are no two steps to commit for DVCSes. There are two steps for commit with Git (stage, then commmit), but that's a Git feature, not a DVCS feature.
I think (please correct me if I'm wrong) that you consider the two steps to be the commit (local) and push (to a central repository). You only need to do that if you want each and every change made by each and every developer to be immediately available to the others.
With centralized systems (i.e. SVN) that is simply unavoidable. With DVCS you can use commits to be backup points instead of publishings.
The difference is that in SVN you cannot afford to commit code that is incomplete, because it affects the whole team (you do, and until you fix it nobody in the team will have usable code). In DVCS you commit (and merge) as you wish (locally) and only synchronize when you have something stable. Once you get used to it, "the SVN way" looks to be unnecessarily constricting.
The way we worked with DVCS was as follows: we (8 developers or so) had one central repository that was synchronized weekly, before each internal release (to the testing team). Each of us would synchronize their sources before the build (pull changes from the server, merge, pull). Then, one of us would make a build on the server machine.
Many times we would have two colleagues working on two sides of a new feature, and synchronizing beta-code only between ourselves. When we would have something stable, we would put it on the server. In the mean time, the other developers didn't have to see incomplete or broken code and the central codebase was kept stable, while we could still commit and have full benefits of source control.
This is good. It means that by virtue of creating a local repository you have 100% full redundancy and the server single failure point is effectively eliminated. If your server HDD crashes, you just clone a local repository from one of the developers to the new server HDD.
But you only synchronize them once per client. After the initial synchronization all subsequent ones are incremental.
You might be surprised. Both Hg and Git compress data before transfer (I'm not sure if SVN does that) and they also compress the repository itself. Considering that these systems store changes instead of files (i.e. change deltas, not full files) the repository might be smaller using a DVCS than when using SVN.
The downside (you can read that "the upside" if you consider redundancy and backup issues) is that you copy the full repository locally with each cloning process.
There's just no need - backup of DVCS repositories is usually a non-issue. Each local system is a full copy of the central repository (containing full history) and the central repository is a full backup of each client repository (synchronized at each push/pull).
With one central repository and one developer you have 100+100% redundancy. With two developers, 100+200% redundancy.
It doesn't get safer than this.
Regarding merging, subversion is broken by design because it SVN doesn't store any metadata to decide how to merge (as SVN tracks files, not changes). When SVN merges, it tries to make educated guesses, which are in trivial cases OK. For non-trivial cases you end up trying to solve a complex (for humans) problem manually when it is your tool/computer that should be doing that.
正如我刚刚记录的那样，Eclipse 中的新星插件是...一个 DVCS（通过 EGit 进行 Git）。
虽然它可能不是您所追求的，但我仍然指出它是 Eclipse 上当前的“新星”，因为所有 Eclipse 项目现在都在 Git 存储库上，并且 Eclipse 致力于为 Git 工具提供良好的支持。
然而，当我将这个新的 VCS 放入我的企业环境中时，这会带来许多挑战，如下所列：
“我们最终可以在企业软件中转向 DVCS 吗？SVN 仍然是开发的“必备工具”吗？”
您需要将源代码库拆分为多个存储库，并将二进制文件外部化到工件存储库，例如 Nexus （请参阅“什么是一个存储库"）。
As I just documented, the new star in term of Eclipse plugin is... a DVCS (Git through EGit).
While it may not be what you are after, I still point this out as the current "new star" on Eclipse, since all Eclipse projects are now on Git repos, and Eclipse is committed to provide a good support for Git tooling.
However, that includes many challenges as I put this new VCS in my enterprise environment, listed here:
"Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?"
You need to split your source base into several repos and externalize binaries to an artifact repository like Nexus (see "What is a repository").