一个新用户的SCM选择？ [英] SCM choice for a new user?

问题描述

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

我是一所听说过的学校的计算机科学专业的学生，​​已经进行了几年的编程（大约8年），所以我写了几行代码。但是因为我从来没有真正分发源码或二进制文件，也没有开发团队（虽然我确信我会！），但我从不需要学习源代码管理系统。我沿着 src / project_name 或 src / class_code / hw_or_project_name 的行写了一个极其无趣的文件夹层次结构，如果我需要将代码发送给朋友或进行评分，这只是一个tarball。

近年来有些事情发生了变化，因为我的项目变得越来越大。带有Time Machine的我的Mac现在每小时进行一次备份 - 这为我节省了很多时间，最近当我对SSH进行重大更改时......然后在几小时后保存并关闭了编辑器中的陈旧副本。 但是，出于某种专业兴趣 - 以及它可能有用的压倒性感觉 - 我决定学习SCMS。现在，我有很多经验作为源代码消费者 - git clone ， svn checkout ， cvs co <​​/ code>，就是这样 - 但不是维护者，提交者或更新者。

我的问题是：我应该学什么？现在，你们中的一群尖叫着为什么要这么做？你会用很多！但我想学习SCM的基础知识，并在最直接的系统中掌握实际使用它的习惯。在我真正需要它们之前，我会做很多概念来内化 - 分支，标签，合并，协作等。

是不是Linus Torvalds。我将维持一个或者几个分支。在我的几十个文件中，我不介意有些操作在一个系统上比其他操作多几百ms。

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

那么，我应该从什么开始？ Subversion或Git？ Mercurial或CVS？ Visual Source Safe或Perforce？ （最后一对是一个笑话）为什么一个在另一个？

感谢您的时间，如果这在错误的部分，我道歉。 b
$ b

编辑谢谢大家！我感谢您的意见。鉴于Git和Hg之间的选择，我可能会使用Git - 任何分歧？其次，为什么不是 Subversion？这似乎是共识（不只是在这里），它是旧的或过时的。这是为什么？

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

解决方案

鉴于Git和Hg之间的选择，可能与Git一起 - 任何分歧？

警告，我是一名水货迷。

Git并不差，但在使用它时有一些怪癖：

• 您可以推入非裸git回购，但这会搞砸在那里的工作副本（它将分支HEAD移动到推送修订，但不更新工作副本。当你不知道这个推，下一个提交将撤消更改它们被推入回购仓库，与刚刚介绍的更改混合在一起）。在hg中，推到非裸回购只需将新的历史记录添加到回购库中，并在下一次提交时获得一个新头，然后您可以将其与已推入的头合并。


• 你不能在裸露和非裸露的仓库之间轻松切换（你可以使用 hg up -r null 来制作一个hg仓库，并且获得工作副本 hg up [some-revision] ）


• 当您通过标记检出旧版本时，远程分支名称或提交哈希你得到一个 独立头（我真的就像那个问题的标题）。这意味着提交没有分支，并且可以被垃圾收集器删除。在hg中，对旧状态的提交会创建一个永久存储的匿名头（您会在提交时收到警告）。
  
• 当您来自SVN时，您必须知道 git revert 和 svn revert 完成完全不同的事情。


• Git启用了所有功能，也可能导致数据丢失（重置，重置）。在hg中，这些功能在那里，但必须在使用之前启用。
  
• git tag 默认为本地标记，全局可见的标签，你需要 git tag -a 或 git tag -s 。在相反的 hg tag 上创建一个全局可见标签，使用 hg tag -l <​​/ code>创建本地标签。



很多人不喜欢mercurial：

• 分支永久存储在项目历史记录中，用于类似git的本地分支书签
a>可以使用

• 没有类似git的远程跟踪分支（尽管书签可以共享，最近有一些工作更像git的分支标签）
>

• 创建一个标签会在项目历史记录中创建一个新的提交（技术上git以相同的方式执行，但隐藏此提交时 更好）


• 您必须启用修改历史记录功能或实验性功能（hg会预先打包许多...，但默认情况下会禁用它们）。这就是为什么很多人认为mercurial的功能比git少。


• 没有任何与mercurial打包在一起的 git rebase -i 必须自己获得第三方histedit扩展。

其次，为什么不是Subversion？这似乎是共识（不只是在这里），它是旧的或过时的。为什么会这样？

Svn不知道分支或标签是什么，它只知道副本。分支和标签是通过约定svn repo包含trunk /，branches /和tags /文件夹来模拟的，但对于svn他们只是文件夹。

合并是svn是一种痛苦，因为旧版本（之前的svn 1.5）不会跟踪合并历史。由于svn1.5 subversion可以跟踪合并历史，但我不知道合并部分现在是否更好。

另一件事是在svn中每个文件和文件夹都有它是自己的版本号。在git和hg中，整个目录结构都有一个版本。这意味着在svn中你可以检出一个旧版本的一个文件，而svn会说你的工作拷贝没有本地修改。当你在git或者hg中签出一个旧版本的文件时，这两个工具都会说你的工作副本很脏，因为这个树不等于他们存储的树。有了颠覆，你甚至可以得到一个Frankenstein版本的源代码，甚至不知道它。

svn中的一个小问题是，它在每个签出的文件夹中放置一个.svn文件夹（我听说谣言说他们想要在1.7中改变这种行为），在那里清理的参考文件存在。这使得像 grep -r foo 这样的工具不仅列出真实的源文件，还列出了这些.svn文件夹中的文件。

当你有大的或不相关的项目时，Svn是有优势的，因为你只能检出一个版本库的子树，而在git和hg中，你只能一次只读取整棵树。还有svn支持锁定，如果你的文件不容易被合并，这是一个有趣的功能。

关键字替换也被svn支持，但是我不会'吨称这是一个功能。

Real easy one here guys. Best justification gets the win.

I'm a computer science student at a school you've heard of, and have been programming for several years now (about 8), so I've written a fair few lines of code. But since I've never really been distributing - source or binaries - nor doing team developing (though I'm sure I will!), I've never needed to learn source code management systems. I have a tremendously boring hierarchy of folders along the lines of src/project_name or src/class_code/hw_or_project_name and if I need to send the code to a friend or for grading, it's just a tarball away.

A few things have changed in recent years, as my projects have gotten bigger. My Mac, with Time Machine, now does hourly backups - this has saved me a fair few times, most recently when I made major changes over SSH... then saved and closed the stale copy in my editor a few hours later.

But, out of a sort of professional interest - along with an overwhelming sense that it could be useful - I've decided to learn SCMS. Now, I have plenty of experience as a source code 'consumer' - git clone, svn checkout, cvs co, that sort of thing - but none as a maintainer, committer, or updater.

My question to you is: what should I learn? Now, a bunch of you are screaming "why one? you'll use many!" but I'd like to learn the basics of SCM, and get in the habits of actually using it, on the most straightforward system. There are a number of concepts I'd do well to internalize - branches, tags, merging, collaboration, etc - before I really need them.

To be clear, I'm no Linus Torvalds. I will be mantaining one, or perhaps a few branches. On my dozens of files, I don't mind if some operations take a few hundred ms more on one system than on others.

Now what do I have? I do have a webhost. They offer Subversion hosting a click away, or I could store other repositories there no problem. For reasons I can't explain, I'm rather partial to Subversion. But that's exactly why I'm reluctant to just jump in. I know Mercurial, Git, and so forth are the hot new things, being distributed, but I'm not sure why this is a benefit. In fact, I'm not quite sure how it could work.

So, what should I start with? Subversion or Git? Mercurial or CVS? Visual Source Safe or Perforce? (that last pair was a joke) And why one over the other?

Thanks for your time, and if this in the wrong section I apologize.

EDIT Thanks all! I appreciate your comments. Given the choice between Git and Hg, I'd probably go with Git - any disagreement? Second, why not Subversion? It seems to be the consensus (not just here) that it's old or otherwise obsolete. Why's that?

EDIT 2 So after reading all the responses and doing some more reading, I've decided to go with Git. "Answer" goes to the best justification, as stated above. Git seems to be more popular than Mercurial, even if it is a bit less clean. I'm pushing changes to my webserver, where I have viewgit installed, and it's working great. The impetus for storing a copy on my webserver is that I'd like to be working from several of my machines, and I expect them to get out of sync. I also expect to have the several working copies out of sync with each other and my server, and I now understand that Subversion is pretty weak at that. There's a lot I'm still trying to work out, but I've got it set up now so that I can pull/clone from http and push over ssh (next step is to set up Gitosis). To a newbie looking to do what I'm doing - you'll find that your "push" commands will work the first time, but any "cloned" copies won't track the changes you make. Git considers this a safety feature... I only slightly understand why, but it has to do with merging. The trick is to use this post-update hook on the server to merge the newly-pushed copy into the server's working copy.

解决方案

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

Warning, I'm a mercurial fanboy.

Git is not bad, but it has some quirks you have to know when you use it:

• You can push into a non-bare git repo, but this will screw up the working copy there (It moves the branch HEAD to the pushed revision, but does not update the working copy. When you are not aware of this push, the next commit will undo the changes which were pushed into the repo, mixed with the changes you just introduced.). In hg a push to a non-bare repo just add the new history to the repo, and you get a new head on your next commit, which you then can merge with the pushed head.
• You can't easily switch between a bare and a non-bare repo (you can make a hg repo bare with hg up -r null, and get a working copy with hg up [some-revision] from a bare one).
• When you check out an older revision by a tag, remote branch name or commit-hash you get a detached head (I really like the title of that question). This means commits there are on no branch, and can get removed by the garbage collector. In hg a commit on an old state create a permanently stored anonymous head (You get a warning on the commit).
• When you come from SVN you have to know that git revert and svn revert do completely different things.
• Git has all features enabled, also the ones which can cause data loss (rebase, reset). In hg these features are there, but must be enabled prior use.
• git tag makes local tags by default, when you want a globally visible tag you need git tag -a or git tag -s. On the opposite hg tag creates a global visible tag, local tags are created with hg tag -l.

Some things many don't like about mercurial:

• Branches are stored permanent in the project history, for git-like local branches bookmarks can be used
• There are no git-like remote tracking branches (although bookmarks can be shared, and recently there's been work on them to work more like git's branch labels)
• Creating a tag creates a new commit in the project history (technically git does it the same way, but is much better at hiding this commit)
• You have to enable features that modify history, or are experimental (hg comes pre-packed with many, ... but they are disabled by default). This is why many think that mercurial has less features than git.
• There is no git rebase -i equivalent packaged with mercurial, you have to get the third-party histedit extension yourself.

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

Svn has no clue what a branch or a tag is, it only know copies. Branches and tags are simulated by having the convention that a svn repo contains a trunk/, branches/ and tags/ folder, but for svn they are only folders.

Merging was a pain in svn, because older versions (prior svn 1.5) dit not track the merge history. Since svn1.5 subversion can track merge history, but I don't know if the merging part is better now.

Another thing is that in svn every file and folder has it's own version number. In git and hg there is one version for the entire directory structure. This means that in svn you can check out an old revision an one file, and svn will say that there are no local changes in your working copy. When you check out an old revision of one file in git or hg, both tools will say your working copy is dirty, because the tree is not equal to their stored tree. With subversion you can get a Frankenstein version of your sources, without even knowing it.

A minor nastiness in svn is that it places a .svn folder in every checked out folder (I heard rumors that they want to change this behavior in 1.7), where the clean reference files for the checked out ones live. This makes tools like grep -r foo not only list the real source files, but also files from these .svn folders.

Svn has an advantage when you have big or unrelated projects, since you can check out only subtrees of a repository, while in git and hg you can get only the whole tree at once. Also does svn support locking, which is an interesting feature if you have files which can't easily be merged.

Keyword substitution is also supported by svn, but I wouldn't call this a feature.

这篇关于一个新用户的SCM选择？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！