svn - 新用户的 SCM 选择？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




真的很容易在这里伙计们。最好的理由获得胜利。

我是您听说过的一所学校的计算机科学专业的学生，​​并且已经编程了几年(大约 8 年)，所以我已经编写了几行代码。但是因为我从来没有真正分发过——源代码或二进制文件——也没有进行过团队开发(尽管我确信我会!)，我从来不需要学习源代码管理系统。我有一个非常无聊的文件夹层次结构 src/project_name或 src/class_code/hw_or_project_name如果我需要将代码发送给 friend 或进行评分，只需一个压缩包即可。

近年来，随着我的项目变得越来越大，一些事情发生了变化。我的带有 Time Machine 的 Mac 现在每小时进行一次备份 - 这已经为我节省了很多时间，最近一次是当我通过 SSH 进行重大更改时......然后几个小时后在我的编辑器中保存并关闭过时的副本。

但是，出于某种专业兴趣 - 以及它可能有用的压倒性感觉 - 我决定学习 SCMS。现在，作为源代码“消费者”，我拥有丰富的经验 - git clone , svn checkout , cvs co ，那种事情 - 但没有作为维护者，提交者或更新者。

我的问题是:我应该学习什么？现在，你们中的一群人都在尖叫“为什么一个？你会用很多!”但我想学习单片机的基础知识，养成实际使用它的习惯，在最直接的系统上。在我真正需要它们之前，我最好将许多概念内化——分支、标签、 merge 、协作等。

需要明确的是，我不是 Linus Torvalds。我将维护一个，或者可能是几个分支。在我的几十个文件中，我不介意某些操作在一个系统上比在其他系统上多花几百毫秒。

现在我有什么？我有一个虚拟主机。他们提供 Subversion 托管，点击一下，或者我可以在那里存储其他存储库没有问题。出于我无法解释的原因，我更偏向于 Subversion。但这正是我不愿意加入的原因。我知道 Mercurial、Git 等是热门的新东西，正在分发，但我不确定为什么这是一个好处。事实上，我不太确定它是如何工作的。

那么，我应该从什么开始呢？颠覆还是 Git？ Mercurial 还是CVS？ Visual Source Safe 还是 Perforce？ (最后一对是一个笑话)为什么一个比另一个？

感谢您的时间，如果这在错误的部分，我深表歉意。

编辑 谢谢大家!我很欣赏你的评论。考虑到 Git 和 Hg 之间的选择，我可能会选择 Git - 有什么不同意见吗？第二，为什么不是Subversion？似乎共识(不仅仅是在这里)它已经过时或过时了。为什么？

编辑 2 因此，在阅读了所有回复并进行了更多阅读之后，我决定使用 Git。如上所述，“答案”是最好的理由。 Git 似乎比 Mercurial 更受欢迎，即使它不太干净。我正在将更改推送到我的网络服务器，在那里我有 viewgit安装了，效果很好。在我的网络服务器上存储副本的动力是我想在我的多台机器上工作，我希望它们不同步。我也希望有几个工作副本与彼此和我的服务器不同步，我现在明白 Subversion 在这方面很弱。我还在努力解决很多问题，但我现在已经设置好了，这样我就可以从 http pull/克隆并推送 ssh(下一步是设置 Gitosis)。对于希望做我正在做的事情的新手 - 您会发现您的“推送”命令将在第一次起作用，但任何“克隆”副本都不会跟踪您所做的更改。 Git 认为这是一个安全特性......我只是稍微理解为什么，但它与 merge 有关。诀窍是使用 this服务器上的 post-update hook 将新推送的副本 merge 到服务器的工作副本中。

Answer 1

Given the choice between Git and Hg, I'd probably go with Git - any disagreement?

警告，我是一个善变的粉丝。

Git 还不错，但它有一些你在使用时必须知道的怪癖:

你可以推送到一个非裸的 git repo，但这会搞砸那里的工作副本(它将分支 HEAD 移动到推送的修订版，但不更新工作副本。当你不知道这个推送时，下一个commit 将撤消推送到 repo 中的更改，以及您刚刚引入的更改。)。在 hg 中，推送到非裸存储库只需将新历史记录添加到存储库，然后您将在下一次提交时获得一个新头，然后您可以将其与推送的头 merge 。

您无法轻松地在裸和非裸 repo 之间切换(您可以使用 hg up -r null 制作一个 hg repo 裸库，并从裸库中获得一个带有 hg up [some-revision] 的工作副本)。

当您通过标签、远程分支名称或提交哈希检查旧版本时，您会得到 detached head (我真的很喜欢这个问题的标题)。这意味着提交不在任何分支上，并且可以被垃圾收集器删除。在 hg 旧状态的提交中创建一个永久存储的匿名头(您在提交时收到警告)。

当您来自 SVN 时，您必须知道 git revert和 svn revert做 完全不同的东西。

Git 启用了所有功能，还有可能导致数据丢失的功能(rebase、reset)。在 hg 中有这些功能，但必须在使用前启用。

git tag默认情况下制作本地标签，当你想要一个全局可见的标签时，你需要 git tag -a或 git tag -s .对面hg tag创建全局可见标签，局部标签使用 hg tag -l 创建.

许多人不喜欢 mercurial 的一些事情:

分支在项目历史中永久存储，用于类似 git 的本地分支 bookmarks可以用

没有类似 git 的远程跟踪分支(虽然书签可以共享，最近有一些工作让它们更像 git 的分支标签)

创建一个标签会在项目历史中创建一个新的提交(技术上 git 也是这样做的，但是 更能 stash 这个提交)

您必须启用修改历史或实验性的功能(hg 预装了许多功能，...但默认情况下它们是禁用的)。这就是为什么许多人认为 mercurial 的功能比 git 少的原因。

没有git rebase -i用 mercurial 打包，你必须得到 third-party histedit extension你自己。

Second, why not Subversion? It seems to be the consensus (not just here) that it's old or otherwise obsolete. Why's that?

Svn 不知道分支或标签是什么，它只知道副本。分支和标签是通过约定 svn 存储库包含主干/、分支/和标签/文件夹来模拟的，但对于 svn 来说，它们只是文件夹。

merge 在 svn 中很痛苦，因为旧版本(svn 1.5 之前的版本)不跟踪 merge 历史。由于svn1.5 subversion 可以跟踪 merge 历史，但不知道现在 merge 部分是否更好。

另一件事是，在 svn 中，每个文件和文件夹都有自己的版本号。在 git 和 hg 中，整个目录结构只有一个版本。这意味着在 svn 中你可以 check out 一个旧版本的一个文件，并且 svn 会说你的工作副本中没有本地更改。当你在 git 或 hg 中 check out 一个文件的旧版本时，这两个工具都会说你的工作副本是脏的，因为树不等于它们存储的树。使用 subversion，您可以获得源代码的 Frankenstein 版本，甚至不知道它。

svn 中的一个小问题是它在每个 check out 文件夹中放置了一个 .svn 文件夹(我听说他们想在 1.7 中改变这种行为)， check out 文件的干净引用文件就在其中。这使得像 grep -r foo 这样的工具不仅会列出真正的源文件，还会列出这些 .svn 文件夹中的文件。

当您有大型或不相关的项目时，Svn 具有优势，因为您只能 check out 存储库的子树，而在 git 和 hg 中，您一次只能获取整个树。 svn 也支持锁定，如果您的文件不易 merge ，这是一个有趣的功能。

svn 也支持关键字替换，但我不会将其称为功能。