这里真的很容易。最好的理由获胜。
我是你所听说过的一所学校的计算机科学专业的学生，现在已经编程了好几年（大约8年），所以我写了几行代码。但是因为我从来没有真正分发过 - 源代码或二进制文件 - 也没有团队开发（虽然我相信我会这样做！），但我从来不需要学习源代码管理系统。我在src/project_name或src/class_code/hw_or_project_name的行中有一个非常无聊的文件夹层次结构，如果我需要将代码发送给朋友或进行评分，那么它只是一个tarball。
近年来，随着我的项目变得更大，一些事情发生了变化。我的Mac，使用Time Machine，现在可以进行每小时备份 - 这几次为我节省了一些时间，最近一次是我通过SSH进行了重大更改...然后在几小时后保存并关闭了我的编辑器中的陈旧副本。
但是，出于某种专业兴趣 - 以及它可能有用的压倒性感觉 - 我决定学习SCMS。现在，作为源代码“消费者”，我有很多经验 - git clone，svn checkout，cvs co，这类事情 - 但没有一个作为维护者，提交者或更新者。 / p>
我的问题是：我应该学习什么？现在，你们中间有一群人在尖叫着“为什么一个人？你会用很多！”但我想学习SCM的基础知识，并在最直接的系统中养成实际使用它的习惯。在我真正需要它之前，我有很多内容要做的概念 - 分支，标签，合并，协作等。
要清楚，我不是Linus Torvalds。我将维护一个，或者几个分支。在我的数十个文件中，我不介意某些操作在一个系统上比在其他系统上花费几百毫秒。
现在我有什么？我有一个虚拟主机。他们提供Subversion托管点击，或者我可以存储其他存储库没有问题。由于我无法解释的原因，我更倾向于Subversion。但这正是我不愿意跳进去的原因。我知道Mercurial，Git等等是热门的新事物，正在分发，但我不确定为什么这是一个好处。事实上，我不太确定它是如何起作用的。
那么，我该怎么做呢？颠覆还是Git？ Mercurial还是CVS？ Visual Source Safe还是Perforce？ （最后一对是一个笑话）为什么一个在另一个？
感谢您的时间，如果这是错误的部分我道歉。
编辑谢谢大家！感谢您的评论。考虑到Git和Hg之间的选择，我可能会选择Git - 任何不同意见？第二，为什么不 Subversion？它似乎是旧的或其他过时的共识（不仅仅是在这里）。为什么？
编辑2 因此，在阅读完所有回复并进行更多阅读后，我决定选择Git。如上所述，“答案”是最好的理由。 Git似乎比Mercurial更受欢迎，即使它不那么干净。我正在将更改推送到我的网络服务器，我安装了viewgit，并且它运行良好。在我的网络服务器上存储副本的动力是我想从我的几台机器上工作，我希望它们不同步。我还希望有几个工作副本彼此不同步和我的服务器，我现在明白Subversion在这方面相当薄弱。有很多我还在努力解决，但我现在已经设置好了，这样我就可以从http中拉出/克隆并推送ssh（下一步是设置Gitosis）。对于想要做我正在做的事情的新手 - 你会发现你的“推送”命令将在第一次工作，但任何“克隆”的副本都不会跟踪你所做的改变。 Git认为这是一个安全功能......我只是略微理解为什么，但它与合并有关。诀窍是在服务器上使用this更新后挂钩将新推送的副本合并到服务器的工作副本中。
答案 0 :(得分：12)
鉴于Git和Hg之间的选择，我可能会选择Git - 任何分歧？
警告，我是一个善变的粉丝。
Git并不坏，但是当你使用它时，你必须知道一些怪癖：
hg up -r null制作hg repo，并从裸露的版本获取hg up [some-revision]的工作副本。 git revert和svn revert 完全不同的事情。 git tag默认情况下制作本地代码，如果您需要全局可见的代码，则需要git tag -a或git tag -s。在相反的hg tag创建全局可见标记，使用hg tag -l创建本地标记。许多人不喜欢mercurial：
git rebase -i等价物，你必须自己获得third-party histedit extension。第二，为什么不Subversion？它似乎是旧的或其他过时的共识（不仅仅是在这里）。为什么？
Svn不知道分支或标签是什么，它只知道副本。通过具有svn repo包含trunk /，branches /和tags /文件夹的约定来模拟分支和标签，但对于svn，它们只是文件夹。
合并是svn的一个难点，因为旧版本（之前的svn 1.5）不能跟踪合并历史记录。由于svn1.5 subversion可以跟踪合并历史记录，但我不知道合并部分现在是否更好。
另一件事是，在svn中，每个文件和文件夹都有自己的版本号。在git和hg中，整个目录结构有一个版本。这意味着在svn中你可以查看旧版本的一个文件，svn会说你的工作副本没有本地更改。当你用git或hg检出一个文件的旧版本时，两个工具都会说你的工作副本是脏的，因为树不等于它们存储的树。使用subversion，您可以获得Frankenstein版本的源代码，甚至不知道它。
svn中的一个小问题是它在每个签出的文件夹中都放了一个.svn文件夹（我听说他们想在1.7中改变这种行为的传闻），其中检查出来的干净参考文件存在。这使得像grep -r foo这样的工具不仅列出了真实的源文件，还列出了这些.svn文件夹中的文件。
当您拥有大型或不相关的项目时，Svn具有优势，因为您只能检出存储库的子树，而在git和hg中，您只能同时获得整个树。还有svn支持锁定，如果你有一些不容易合并的文件，这是一个有趣的功能。
svn也支持关键字替换，但我不会将此称为功能。
答案 1 :(得分：10)
我会选择mercurial。
答案 2 :(得分：9)
Git和Mercurial现在可以通过线路互相读取和写入彼此的回购，因此它真正归结为您喜欢的任何接口。
答案 3 :(得分：5)
有一件事是肯定的，不要从CVS开始。
答案 4 :(得分：3)
我一直在使用Mercurial，非常喜欢它。您可以获得免费的Bitbucket帐户并开始将您的存储库存储在云端。如果您有希望/机会参与编码复合体上的OSS项目，它也会被用于某些编码复合项目。
我发现/听到的基本要点是Mercurial更容易使用但不如Git强大。但是，两者都是很好的选择。
tekpub for Mercurial and Codeplex上有一个非常好的免费视频。它将带您了解所有基础知识。
如前所述，http://hginit.com链接是另一个很好的资源。它也是由制作FogBugz＆amp; amp;窑。 Kiln是Mercurial和FogBugz的集成环境，具有代码审查等附加功能。
我在我当地的盒子上使用SVN存储我的个人作品但不再存在。随着Bitbucket＆amp; Mercurial我不必担心我当地的盒子死亡，并确保我已经备份了所有东西....
底线是你不能用Hg或Git出错，但除非你需要一些你听不到的高级功能，否则我会选择Hg。
学习SVN并不一定是坏事，因为有很多组织使用它，但我真的会专注于分布式VCS。他们真的是未来。 ： - ）
答案 5 :(得分：1)
作为一个新手，我已经使用git，发现它非常易于使用和直观，而其他人有点过于庞大。与GitHub相结合，它为源代码控制，共享和支持提供了一个很棒的小工具代码。
答案 6 :(得分：0)
最好的开源选择是GIT。检查Git documentation。你也可以通过互联网找到很多tutos（youtube和一些开发者博客）。一定不能做（开始使用CVS或Subversion）。至少是我的个人意见。
答案 7 :(得分：0)
曾几何时， cvs 几乎完全取代了它的竞争对手，并统治了版本控制的世界。
然后它本身被 svn 取代。
现在，svn正在被 git 取代。
Git 比 svn 更复杂，因此可能仍然是选择 svn 的理由项目
但它的日子已经屈指可数了。 Git ， Mercurial ，一些专有系统显然是VCS世界的未来。
git和svn都可以用于cvs-like checkout / pull / commit模式，所以git的无底洞复杂（这是一种生活方式）不会影响你，除非你跳到深处。 / p>