新用户的SCM选择？

发布于 2024-10-07 15:40:14 字数 1814 浏览 0 评论 0原文

伙计们，这里真的很简单。最好的理由获得胜利。

我是您听说过的一所学校的计算机科学专业的学生，并且已经编程好几年了（大约 8 年），所以我已经编写了相当多的代码行。但由于我从未真正分发过源代码或二进制文件，也从未进行过团队开发（尽管我确信我会！），所以我从来不需要学习源代码管理系统。我有一个非常无聊的文件夹层次结构，类似于 src/project_name 或 src/class_code/hw_or_project_name ，如果我需要将代码发送给朋友或进行评分，只需一个 tarball 即可。

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

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

我问你的问题是：我应该学什么？现在，你们中的一群人尖叫着“为什么一个？你会用很多！”但我想学习 SCM 的基础知识，并养成在最简单的系统上实际使用它的习惯。在我真正需要之前，我应该很好地内化许多概念 - 分支、标签、合并、协作等。

需要明确的是，我不是莱纳斯·托瓦兹。我将保留一个或几个分支机构。对于我的数十个文件，我不介意某些操作在一个系统上比在其他系统上多花费几百毫秒。

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

那么，我应该从什么开始呢？ Subversion 还是 Git？ Mercurial 还是 CVS？视觉源安全还是 Perforce？（最后一对是个笑话）为什么一个比另一个呢？

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

编辑谢谢大家！我很欣赏你的评论。考虑到 Git 和 Hg 之间的选择，我可能会选择 Git - 有什么不同意见吗？其次，为什么不Subversion？似乎人们一致认为（不仅仅是这里）它已经过时或过时了。这是为什么呢？

编辑 2 因此，在阅读了所有回复并进行了更多阅读之后，我决定使用 Git。如上所述，“答案”指向最佳理由。 Git 似乎比 Mercurial 更流行，尽管它不太干净。我正在将更改推送到我的网络服务器，我在其中安装了 viewgit，并且运行良好。在我的网络服务器上存储副本的动机是我想在我的几台机器上工作，并且我希望它们不同步。我还希望几个工作副本彼此之间以及我的服务器不同步，而且我现在了解到 Subversion 在这方面相当薄弱。还有很多事情我仍在尝试解决，但我现在已经设置好了，这样我就可以从 http 拉取/克隆并通过 ssh 推送（下一步是设置 Gitosis）。对于想要做我正在做的事情的新手 - 你会发现你的“推送”命令第一次就能工作，但任何“克隆”副本都不会跟踪你所做的更改。 Git 认为这是一个安全功能...我只是稍微理解为什么，但它与合并有关。技巧是在服务器上使用 this 更新后挂钩来合并新推送的内容复制到服务器的工作副本中。

原文

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.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

謌踐踏愛綪 2024-10-14 15:40:14

考虑到 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 创建本地标签。

许多人不喜欢 Mercurial 的一些事情：

对于类似 git 的本地分支，分支永久存储在项目历史记录中可以使用书签
没有类似 git 的远程跟踪分支（尽管书签可以共享，并且最近有人对它们进行了研究，使其更像 git 的分支标签）
创建标签会创建一个新的标签在项目历史记录中提交（从技术上讲，git 以相同的方式执行此操作，但在隐藏此提交方面更好）
您必须启用修改历史记录的功能，或者是实验性的（hg 预装了许多功能），...但默认情况下它们是禁用的）。这就是为什么许多人认为 Mercurial 的功能比 git 少。
Mercurial 中没有等效的 git rebase -i ，您必须获取第三方 histedit 扩展自己。

第二，为什么不使用 Subversion？似乎人们一致认为（不仅仅是这里）它已经过时或过时了。这是为什么？

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

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

另一件事是，在 svn 中，每个文件和文件夹都有自己的版本号。在 git 和 hg 中，整个目录结构有一个版本。这意味着在 svn 中你可以签出一个文件的旧版本，并且 svn 会说你的工作副本中没有本地更改。当您在 git 或 hg 中检查一个文件的旧版本时，这两个工具都会说您的工作副本是脏的，因为树不等于它们存储的树。通过颠覆，你可以在不知情的情况下获得你的资源的弗兰肯斯坦版本。

svn 中的一个小问题是它在每个签出文件夹中放置一个 .svn 文件夹（我听说他们想在 1.7 中更改此行为），其中存放签出文件夹的干净参考文件。这使得像 grep -r foo 这样的工具不仅列出了真正的源文件，而且还列出了这些 .svn 文件夹中的文件。

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

svn 也支持关键字替换，但我不认为这是一个功能。

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.

回复收藏 0 原文