SCM选择新用户？

Rob*_*ert 7 svn git cvs version-control mercurial

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

我是你所听说过的一所学校的计算机科学专业的学生,现在已经编程好几年了(大约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等等是热门的新事物,正在分发,但我不确定为什么这是一个好处.事实上,我不太确定它是如何起作用的.

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

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

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

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

Rud*_*udi 12

考虑到Git和Hg之间的选择,我可能会选择Git - 任何分歧？

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

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

你可以推入一个非裸的git仓库,但这会搞砸那里的工作副本(它将分支HEAD移动到推送的版本,但不会更新工作副本.当你不知道这个推动时,下一个commit将撤消推送到repo中的更改,并与您刚刚引入的更改混合使用.)在hg中,推送到非裸仓库只需将新历史记录添加到仓库中,然后在下次提交时获得新头,然后您可以将其与推送头合并.
你不能轻易地在裸露和非裸露的回购之间切换(你可以用一个hg repo裸露hg up -r null,并hg up [some-revision]从裸露的版本获得一份工作副本).
当您通过标签,远程分支名称或commit-hash签出旧版本时,您会获得一个独立的头部(我非常喜欢该问题的标题).这意味着提交没有分支,并且可以被垃圾收集器删除.在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的本地分支书签
没有类似git的远程跟踪分支(尽管书签可以共享,最近有一些工作就像git的分支标签一样工作)
创建标记会在项目历史记录中创建一个新的提交(技术上git以相同的方式执行,但在隐藏此提交方面要好得多)
您必须启用修改历史记录的功能,或者是实验性功能(hg预先包含许多功能,...但默认情况下禁用它们).这就是为什么许多人认为mercurial的功能少于git.
没有git rebase -i与mercurial打包的等价物,你必须自己获得第三方的hetedit扩展.

二,为什么不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也支持关键字替换,但我不会将此称为功能.

dha*_*ble 10

我会选择mercurial.