我已经经历了版本控制的磨坊。不管你信不信，我从 sccs 开始。曾与 RCS 合作。转移到CVS。被迫使用 Visual SourceSafe，并且讨厌它。对 Subversion 非常满意。
我一直在研究新的分布式 VCS - Git、Hg 等。它们看起来很复杂。我怀疑他们是否比 SVN 提供了足够的优势，以至于值得花时间让整个团队转移到其中一个。
但我在想。据我了解，与 SVN 相比，Git 有两个真正的变化。首先，分布式存储库。其次，通过变更集而不是版本来管理合并。
我不认为我是唯一一个认为第一个优势毫无意义的人。对于我们的业务，我们需要一个单一的存储库。 SVN 可以做到这一点，Git 也可以做到这一点。 Git 可以管理分布式存储库，这对其他人来说可能有很多好处，但对我们来说却一点好处也没有。
不过，通过变更集管理合并会让我们受益。我们正在管理具有多个分支的多个项目，其中一些子项目由多个父项目共享。使用 SVN 管理需要跨这些分支进行的更改比使用 CVS 容易得多，但它绝不是轻松的。 Git 的变更集方法看起来会带来真正的好处。
我想知道 Git 增加的复杂性有多少是由于使用多个存储库造成的，有多少是由于使用变更集而固有的？使用变更集但不提供多个存储库的 VCS 是否可以比 Git 更简单？
有没有比 Git 更容易使用的、可处理变更集的 VCS？
I've been through the mill with version control. I started with sccs, believe it or not. Worked with RCS. Moved to CVS. Was forced to use Visual SourceSafe, and hated it. Have been pretty happy with Subversion.
I've been looking at the new distributed VCS - Git, Hg, etc. They look complicated. I have doubts over whether they provide enough of an advantage over SVN to make it worth the time it would take to get the entire team moved over to one of them.
But I was thinking. From what I've read there are two real changes in Git as compared to SVN. First, the distributed repositories. Second, managing merging through change sets, instead of with versions.
I don't think I'm the only one for whom the first advantage is meaningless. For our business, we need a single repository. SVN does this, Git can do this. That Git can manage distributed repositories, as much a benefit as it may be to others, benefits us not at all.
Managing merging through change sets, though, is something that would benefit us. We're managing multiple projects, with multiple branches, with some child projects being shared by multiple parent projects. Managing changes that need to be made across these branches is a lot easier with SVN than it was with CVS, but it's by no means pain-free. Git's change-set approach looks like it would be a real benefit.
What I'm wondering is how much of Git's added complexity is due to the use of multiple repositories, and how much is inherent in working with change sets? Could a VCS that used change sets, but did not provide for multiple repositories, be simpler than Git?
And are there any VCS that work with change sets that are simpler to use than Git?
发布评论
评论（4）
Subversion确实有变更集的概念，您可以指定变更集 使用 -c 选项。您可以合并单个变更集或一系列变更集。在幕后，这实际上就是 Subversion 在 /db/revs/ 中存储每次提交的方式（至少对于基于文件的存储来说是这样）。
与 Subversion 相比，我认为 Git 的一个优势是，当将多个变更集从分支 A 合并到分支 B 时，分支 B 保留每个单独的变更集，而在 Subversion 中，它被压缩在一起作为一个变更集，并且“看起来”像所有变更由提交合并的用户完成。虽然您可以按照历史记录回到旧分支来查看 Subversion 中的每个变更集，但这并不方便。
Git 还有一些强大的命令来查看分支之间变更集的差异。 Subversion 1.5 中引入的合并跟踪尝试执行类似的操作，但恕我直言，它过于复杂且不直观。
Subversion does have a concept of changesets, you can specify a changeset with the -c option. You can merge individual changesets, or a range of changesets. Behind the scenes, this is actually how Subversion stores each commit, in /db/revs/ (for file based storage at least).
What I see as an advantage in Git compared to Subversion, is that when merging multiple changsets from branch A to branch B, branch B retains each individual changeset, while in Subversion it gets squeezed together as one changeset and it "looks" like all changes are done by the user who committed the merge. While you can follow the history back to the old branch to see each changeset in Subversion, it's not that convenient.
Git also has some powerful commands to see the differences of changesets between branches. The merge tracking introduced in Subversion 1.5 tries to do something like this, but is IMHO overcomplicated and not intuitive.
我不确定“变更集”或“版本”是什么意思。在我看来，事实恰恰相反。 git 存储数据的方式是存储每个文件的完整内容。另一方面，SVN 只存储新版本的差异。
分布式存储库功能是一个被极度低估的功能。在我转向 git 之前，我也没有看到它的潜力。但拥有本地提交和本地分支是一个杀手级功能。
SVN 有外部处理子存储库。在 git 中，这称为子模块（有点不同）。这不应该是决定因素，因为 SVN 和 git 都支持它。当然，除非你不喜欢 git 的做法。
我建议你观看这个名为 获取 git 的演讲，它将解释 git 的工作原理。特别是“VCS 分类法”幻灯片很好地解释了不同 VCS 之间的根本区别。
I'm not sure what you mean by "changesets" or "versions". It seems to me like it is in fact exactly the other way round. The way git stores its data is by storing the full content of each file. SVN on the other hand only stores the diffs of new versions.
The distributed repository feature is one that is extremely underestimated. Before I switched to git I did not see the potential yet either. But having local commits and local branches is a killer feature.
SVN has externals to deal with sub-repositories. In git this is called submodules (it's a bit different). This should not be a deciding factor, since both SVN and git support it. Except if you don't like how git does it, of course.
I suggest you watch this talk called getting git, it will explain how git works. Especially the "VCS taxonomy" slide does a good job of explaining the fundamental difference between different VCS' out there.
我想说 git 的学习曲线对于任何类型的使用都是非常值得的。
我不太确定您在“更改集”方面所描述的内容，但 darcs 用“补丁集”来谈论可能相似的事物。它也是 DVCS，但有所不同。我不太了解 darcs 和 git，尽管我偶尔被迫使用它。这可能就是您正在寻找的。
我认为故意试图避免 DVCS 是一个错误。您仍然可以完全使用一个中央存储库。分布式部分非常适合在与互联网断开连接时工作，而且也非常可靠。您不依赖服务器。当我在火车上 6 小时完成我的项目时，我可以完成大量工作，因为我不受服务器的束缚。如果服务器出现问题，当每个拥有签出副本的人都拥有整个副本时，您不会丢失任何内容。
I would say the learning curve of git and is well worth it for any type of use.
I'm not exactly sure what you're describing in terms of "change sets," but darcs talks about things in terms of "patch sets" which may be similar. It's also a DVCS, but rather different. I don't really understand darcs as well as git, though I am occasionally forced to use it. It may be what you're looking for.
I think intentionally trying to avoid DVCS is a mistake. You can still entirely use one central repository. The distributed part is wonderful for working when disconnected from the internet, and also great for reliability. You aren't dependent on the server. I get lots of work done when I'm on a train for 6 hours on my projects since I'm not tied to the server. In the event of a server issue, when every person with a checked out copy has the entire copy, you don't lose anything.
阅读这篇博客文章，了解为什么 git 可能比您想象的更适合您的企业环境（全面披露：我写了这篇文章）：
Git 在企业环境中的优势
不过，如果你坚持中心化模式，Bazaar 可以采用中心化模式运行。不过，在阅读完这篇博客文章后，您将有望明白为什么集中式模式实际上存在缺点。
Read this blog post for some ideas of why git might be a lot better for your corporate environment than you think (full disclosure: I wrote the post):
Git advantages in corporate environment
However, if you insist on a centralized model, Bazaar can operate in a centralized mode. After reading the blog post though, you'll hopefully see why in fact there's disadvantages to the centralized mode.