svn – 新用户的SCM选择?

这里真的很容易.最好的理由获得胜利.

我是你所听说过的一所学校的计算机科学专业的学生,​​现在已经编程好几年了(大约8年),所以我写了几行代码.但是因为我从来没有真正分发过 – 源代码或二进制文件 – 也没有团队开发(尽管我确定会这样做!),但我从来不需要学习源代码管理系统.我有一个非常无聊的文件夹层次结构,沿着src / project_name或src / class_code / hw_or_project_name的行,如果我需要将代码发送给朋友或进行评分,那只是一个tarball.

随着我的项目变得越来越大,近年来发生了一些变化.我的Mac,使用Time Machine,现在可以进行每小时备份 – 这几次为我节省了一些时间,最近我通过SSH进行了重大更改…然后几小时后在我的编辑器中保存并关闭了陈旧的副本.

但是,出于某种专业兴趣 – 以及它可能有用的压倒性感觉 – 我决定学习SCMS.现在,我有很多作为源代码’消费者’的经验 – git clone,svn checkout,cvs co,那种东西 – 但没有作为维护者,提交者或更新者.

我的问题是:我应该学习什么?现在,你们中间有一群人尖叫着“为什么一个人?你会用很多!”但我想学习SCM的基础知识,并在最简单的系统上养成实际使用它的习惯.在我真正需要它之前,我有很多内容要做的概念 – 分支,标签,合并,协作等.

要清楚,我不是Linus Torvalds.我将维护一个,或者几个分支.在我的几十个文件中,我不介意某些操作在一个系统上比在其他系统上多花几百毫秒.

现在我有什么?我有一个虚拟主机.他们提供Subversion托管点击,或者我可以存储其他存储库没有问题.由于我无法解释的原因,我更倾向于Subversion.但这正是我不愿意跳进去的原因.我知道Mercurial,Git等等是热门的新事物,正在分发,但我不确定为什么这是一个好处.事实上,我不太确定它是如何工作的.

那么,我该怎么做呢? Subversion还是Git? Mercurial还是CVS? Visual Source Safe还是Perforce? (最后一对是一个笑话)为什么一个在另一个?

谢谢你的时间,如果在错误的部分,我道歉.

编辑全部谢谢!感谢您的评论.考虑到Git和Hg之间的选择,我可能会选择Git – 任何分歧?二,为什么不Subversion?它似乎是旧的或其他过时的共识(不仅仅是在这里).为什么?

编辑2因此,在阅读了所有的回复并做了一些阅读之后,我决定选择Git.如上所述,“答案”是最好的理由. Git似乎比Mercurial更受欢迎,即使它不那么干净.我正在将更改推送到我的网络服务器,我已经安装了viewgit,并且它运行良好.在我的网络服务器上存储副本的动力是我想从我的几台机器上工作,我希望它们不同步.我还希望有几个工作副本彼此不同步和我的服务器,我现在明白Subversion在这方面相当薄弱.有很多我还在尝试解决,但我现在已经设置好了,这样我就可以从http中拉出/克隆并推送ssh(下一步是设置Gitosis).对于想要做我正在做的事的新手 – 你会发现你的“推送”命令将在第一次工作,但任何“克隆”的副本都不会跟踪你所做的改变. Git认为这是一个安全功能…我只是略微理解为什么,但它与合并有关.诀窍是在服务器上使用this更新后挂钩将新推送的副本合并到服务器的工作副本中.

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

警告,我是一个善变的粉丝.

Git也不错,但是当你使用它时你必须知道一些怪癖:

>你可以推入一个非裸git仓库,但这会搞砸那里的工作副本(它将分支HEAD移动到推送的版本,但不会更新工作副本.当你不知道这个推动时,下一次提交将撤消推送到repo中的更改,并与您刚刚引入的更改混合使用.在hg中,推送到非裸仓库只需将新历史记录添加到仓库中,然后在下次提交时获得新的头,然后您可以将其与推送头合并.
>你不能轻易地在裸露和非裸露的回购之间切换(你可以用hg up -r null制作一个hg repo裸露,并从裸露的那个获得hg up [some-revision]的工作副本).
>当您通过标签,远程分支名称或commit-hash签出旧版本时,您将获得detached head(我非常喜欢该问题的标题).这意味着提交没有分支,并且可以被垃圾收集器删除.在hg中,对旧状态的提交会创建一个永久存储的匿名头(在提交时会收到警告).
>当你来自SVN时,你必须知道git revert和svn revert做完全不同的事情.
> Git启用了所有功能,也可能导致数据丢失(rebase,reset).在hg中有这些功能,但必须在使用前启用.
> git tag默认使用本地标签,当你想要一个全局可见的标签时,你需要git tag -a或git tag -s.在相反的hg标记上创建全局可见标记,使用hg标记-l创建本地标记.

有些事情很多人不喜欢mercurial:

>分支在项目历史中永久存储,可以使用类似git的本地分支bookmarks
>没有类似git的远程跟踪分支(尽管书签可以共享,最近有一些工作就像git的分支标签一样工作)
>创建标记会在项目历史记录中创建一个新的提交(技术上git以相同的方式执行,但在隐藏此提交方面要好得多)
>您必须启用修改历史记录的功能,或者是实验性功能(hg预先包含许多功能,…但默认情况下禁用它们).这就是为什么许多人认为mercurial的功能少于git.
>没有与mercurial打包的git rebase -i等价物,你必须自己获得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 repo包含trunk /,branches /和tags /文件夹的约定来模拟分支和标签,但对于svn,它们仅是文件夹.

合并是svn的痛苦,因为旧版本(之前的svn 1.5)不能跟踪合并历史.由于svn1.5颠覆可以跟踪合并历史,但我不知道合并部分现在是否更好.

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

svn中的一个小麻烦就是它在每个签出的文件夹中都放了一个.svn文件夹(我听说他们想在1.7中改变这种行为的传闻),其中已检出的干净参考文件存在.这使像grep -r foo这样的工具不仅列出了真正的源文件,还列出了这些.svn文件夹中的文件.

当您拥有大型或不相关的项目时,Svn具有优势,因为您只能检出存储库的子树,而在git和hg中,您只能同时获得整个树.还有svn支持锁定,如果你有不能轻易合并的文件,这是一个有趣的功能.

svn也支持关键字替换,但我不会将此称为功能.

相关文章
相关标签/搜索