新用户的单片机选择? [英] SCM choice for a new user?

问题描述

伙计们，这里真的很简单.最好的理由就是胜利.

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

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

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.

推荐答案

考虑到 Git 和 Hg 之间的选择，我可能会选择 Git - 有什么不同意见吗?

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

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

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

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

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

• 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.

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

Some things many don't like about mercurial:

• 分支永久存储在项目历史记录中，用于类似 git 的本地分支书签 可以使用
• 没有类似 git 的远程跟踪分支(虽然书签可以共享，最近有一些工作让它们更像 git 的分支标签)
• 创建标签会在项目历史记录中创建一个新的提交(从技术上讲，git 以相同的方式执行此操作，但在隐藏此提交方面要好得多)
• 您必须启用修改历史或实验性的功能(hg 预装了许多功能，...但默认情况下它们是禁用的).这就是为什么许多人认为 mercurial 的功能比 git 少的原因.
• 没有与 mercurial 打包的 git rebase -i 等效项，您必须获得 第三方 histedit 扩展程序 自己.

• 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.

第二，为什么不是 Subversion?似乎共识(不仅仅是在这里)它已经过时或过时了.这是为什么?

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/、branch/和tags/文件夹来模拟的，但对于svn它们只是文件夹.

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.

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

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.

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

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.

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

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 具有优势，因为您只能检出存储库的子树，而在 git 和 hg 中，您一次只能获取整个树.svn 是否也支持锁定，如果您的文件不易合并，这是一个有趣的功能.

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.

svn 也支持关键字替换，但我不会称之为功能.

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

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