This is a huge topic and will be impossible to provide a single all-encompassing answer. Nonetheless here are a few thoughts, assuming you are looking for more of a Software Configuration Management solution rather than a simple Revision Control System type approach:
Release Management:
In addition to concurrency control (check-in, check-out, etc.) your SCM can/should also provide history, tagging, branching, and other release management type capabilities. That is, it should always provide a single source of truth as to what source files when into which release, service packs, etc. In order to do this, your build environment needs to be well integrated into your SCM.
WIP Management:
A good SCM system will allow to you compare your work-in-progress to the latest checked in revision. It should also let you revert your WIP, shelve it temporarily, or merge another's changes on a file by file basis.
Documentation & Training
Do not underestimate how important it is to use a tool that can give you a ton of help, books, documentation, community support, and even paid support if needed. Also selecting a "popular" tool can mean that some new developers have one less thing to learn.
Continuous Integration:
Automated builds are a must for any serious organization and you should pick an SCM that can be access by your build systems (e.g. Hudson, CruiseControl, Bamboo, etc.)
Security
The SCM system should have a built in authentication system and also be able to use outside authentication providers as many organizations change over time. In addition, it should be able to support developers working outside the firewall, preferrably over http.
IDE and Build Tool Integration
To make all this stuff easier your SCM must be able to be seamlessly linked into your development system and any command line tools you use. This fact is made easier by the fact that almost all non-Microsoft IDE's support all SCM tools.
Source Browsing
Most SCM tools that I've seen have a number of very high quality, third party browsers such as Fisheye. So I discount this as a differentiating factor.
So which tool to use?
If your organization is fairly well contained within your company then pick Subversion. It is very popular, integrates with every IDE/OS/Build tool, works with ToroiseSVN, supports all platforms, supports multiple protocols, several UI, a powerful command line, a huge community, is free, and is rock solid. It also has an excellent free book.
If you have a highly distributed development group and/or expect to receive open-source contributions from many different folks, go with the distributed capabilities of Git.
Beyond these two, save yourself a ton of time and hassle and forget everything else....really. I realize I am being opinionated, but you kinda asked for an opinion.
Use mercurial (aka hg), and start by learning it in the command line. That way you will learn all basic concepts, which could be somewhat hidden from you when using only GUI overlay such as TortoiseHG. All with a good simplistic tutorial of course, perhaps widely known hginit which covers some simple usage scenarios.
That would be answer to "What else should I know" part, at least for a start. You can then explore by yourself, having a limited, but somewhat solid base. Or, at least, you will be able to ask more concise questions to learn more, or make more sense of the SO question you quote. Your question is somewhat broader than this, of course, but I would advise not to try to grasp everything at once. Each system has it's own quirks and specialties, but you shouldn't be worried by that fact now. Just as with programming -- you should not try to learn many languages at once, if you don't know any yet.
Ah, and as a finishing touch: Tortoise(xxx) is not exactly a revision control system, thats just a typical name for a shell-integrated Windows client to system xxx. As far as I'm concerned, the "Tortoise" part refers to "shell".
PS. the "Mercurial" advice is due to my personal taste of course, but also by the feeling that learning Hg will enable you to grasp most of the ideas from other systems quite easy (if you ever need to).
From my personal experience I would recommend looking at the new generation of 'Source Control Systems' that are called Distributed Version Control Systems. These are systems like Git (and I think Mercurial but I haven't used that.) that actaully store a full version control system locally and when you commit to the remote repository (push in git terms) you push the changes in your local version control system to the master version control system on the server.
Also Git is designed to make Branching a breeze. In systems like Subversion branching is not as easy but with Git Branching is the recommended practice of making changes. I have used Git, Subversion (SVN) and SourceSafe(the worst Source control System of the three by far!) and this is the major advantage of Git over more traditional Source Control Systems.
For Example if you are fixing a bug or adding a feature in a code base that uses SVN the standard practice would be to
Check out the branch you are going to work in.
Make any bug fixes and test them.
Checkin the changes.
With Git or Similar systems you would
Branch the master branch locally (i.e. development, producton version 1.1, etc.).
Make any bug fixes and test in your locally branched version (i.e. you made a jira-123-bugfix branch for version 1.1).
Merge the branch back into your local copy of the master branch that you created it from and make sure everything is OK.
Then push the changes you made to your local copy of the master branch to the central Git repository.
The advantage of this is that if you have to go back and revist the bug fix you still have your local copy of that branch.
发布评论
评论（3）
这是一个巨大的话题，不可能提供一个包罗万象的答案。尽管如此，假设您正在寻找更多的软件配置管理解决方案而不是，这里有一些想法一个简单的修订控制系统类型的方法：
管理：
发布 并发控制（签入、签出等）您的 SCM 还可以/应该提供历史记录、标记、分支和其他发布管理类型的功能。也就是说，它应该始终提供关于哪些源文件、何时进入哪个版本、服务包等的单一事实来源。为了做到这一点，您的构建环境需要很好地集成到您的 SCM 中。
WIP 管理：
良好的 SCM 系统将允许您将正在进行的工作与最新签入的修订进行比较。它还应该允许您恢复 WIP、暂时搁置它或逐个文件地合并其他人的更改。
文档和培训
不要低估使用可以为您提供大量帮助、书籍、文档、社区支持甚至付费支持（如果需要）的工具的重要性。此外，选择“流行”工具可能意味着一些新开发人员需要学习的东西少了。
持续集成：
自动化构建对于任何严肃的组织来说都是必须的，您应该选择一个可以由您的构建系统访问的 SCM（例如 Hudson、CruiseControl、Bamboo 等）
安全性
的身份验证系统，并且还能够使用外部身份验证提供程序，因为许多组织随着时间的推移而发生变化。此外，它应该能够支持开发人员在防火墙之外工作，最好是通过 http。
IDE 和构建工具集成
为了使所有这些工作变得更容易，您的 SCM 必须能够无缝链接到您的开发系统和您使用的任何命令行工具。由于几乎所有非 Microsoft IDE 都支持所有 SCM 工具，这一事实变得更加容易。
源浏览
我见过的大多数 SCM 工具都有许多非常高质量的第三方浏览器，例如 Fisheye。所以我认为这是一个差异化因素。
那么该使用哪个工具？
如果您的组织很好地包含在您的公司中，那么请选择 Subversion。它非常流行，与每个 IDE/OS/Build 工具集成，与 ToroiseSVN 配合使用，支持所有平台，支持多种协议、多种 UI、强大的命令行、庞大的社区、免费且坚如磐石。它还拥有一本优秀的免费书籍。
如果您有一个高度分布式的开发团队和/或期望收到来自许多不同人员的开源贡献，请使用 Git 的分布式功能。
除了这两者之外，可以为自己节省大量时间和麻烦，忘记其他一切......真的。我知道我固执己见，但你有点征求意见。
This is a huge topic and will be impossible to provide a single all-encompassing answer. Nonetheless here are a few thoughts, assuming you are looking for more of a Software Configuration Management solution rather than a simple Revision Control System type approach:
Release Management:
In addition to concurrency control (check-in, check-out, etc.) your SCM can/should also provide history, tagging, branching, and other release management type capabilities. That is, it should always provide a single source of truth as to what source files when into which release, service packs, etc. In order to do this, your build environment needs to be well integrated into your SCM.
WIP Management:
A good SCM system will allow to you compare your work-in-progress to the latest checked in revision. It should also let you revert your WIP, shelve it temporarily, or merge another's changes on a file by file basis.
Documentation & Training
Do not underestimate how important it is to use a tool that can give you a ton of help, books, documentation, community support, and even paid support if needed. Also selecting a "popular" tool can mean that some new developers have one less thing to learn.
Continuous Integration:
Automated builds are a must for any serious organization and you should pick an SCM that can be access by your build systems (e.g. Hudson, CruiseControl, Bamboo, etc.)
Security
The SCM system should have a built in authentication system and also be able to use outside authentication providers as many organizations change over time. In addition, it should be able to support developers working outside the firewall, preferrably over http.
IDE and Build Tool Integration
To make all this stuff easier your SCM must be able to be seamlessly linked into your development system and any command line tools you use. This fact is made easier by the fact that almost all non-Microsoft IDE's support all SCM tools.
Source Browsing
Most SCM tools that I've seen have a number of very high quality, third party browsers such as Fisheye. So I discount this as a differentiating factor.
So which tool to use?
If your organization is fairly well contained within your company then pick Subversion. It is very popular, integrates with every IDE/OS/Build tool, works with ToroiseSVN, supports all platforms, supports multiple protocols, several UI, a powerful command line, a huge community, is free, and is rock solid. It also has an excellent free book.
If you have a highly distributed development group and/or expect to receive open-source contributions from many different folks, go with the distributed capabilities of Git.
Beyond these two, save yourself a ton of time and hassle and forget everything else....really. I realize I am being opinionated, but you kinda asked for an opinion.
如果我要给你建议的话，那就是
这将是“我还应该知道什么”部分的答案，至少是一个开始。然后，您可以自己探索，基础有限，但有些坚实。或者，至少，您将能够提出更简洁的问题来了解更多信息，或者更理解您引用的问题。当然，你的问题比这更广泛，但我建议不要试图立即掌握所有内容。每个系统都有自己的怪癖和特点，但您现在不应该为此担心。就像编程一样——如果您还不了解任何一种语言，就不应该尝试一次学习多种语言。
啊，最后一点：Tortoise(xxx) 并不完全是一个版本控制系统，这只是系统 xxx 的 shell 集成 Windows 客户端的典型名称。就我而言，“龟”部分指的是“壳”。
附言。 “Mercurial”的建议当然是出于我个人的品味，但也因为学习 Hg 将使您能够很容易地掌握其他系统的大部分想法（如果您需要的话）。
If I was to advise something to you, it would be
That would be answer to "What else should I know" part, at least for a start. You can then explore by yourself, having a limited, but somewhat solid base. Or, at least, you will be able to ask more concise questions to learn more, or make more sense of the SO question you quote. Your question is somewhat broader than this, of course, but I would advise not to try to grasp everything at once. Each system has it's own quirks and specialties, but you shouldn't be worried by that fact now. Just as with programming -- you should not try to learn many languages at once, if you don't know any yet.
Ah, and as a finishing touch: Tortoise(xxx) is not exactly a revision control system, thats just a typical name for a shell-integrated Windows client to system xxx. As far as I'm concerned, the "Tortoise" part refers to "shell".
PS. the "Mercurial" advice is due to my personal taste of course, but also by the feeling that learning Hg will enable you to grasp most of the ideas from other systems quite easy (if you ever need to).
根据我的个人经验，我建议您查看新一代的“源代码控制系统”，即分布式版本控制系统。这些系统像 Git（我认为是 Mercurial，但我没有使用过），实际上在本地存储完整的版本控制系统，当您提交到远程存储库（用 git 术语来说是推送）时，您会将更改推送到本地版本中控制系统到服务器上的主版本控制系统。
此外，Git 的设计目的是使分支变得轻而易举。在像 Subversion 这样的系统中，分支并不那么容易，但在 Git 中，分支是建议进行更改的做法。我使用过 Git、Subversion (SVN) 和 SourceSafe（迄今为止这三个系统中最差的源代码控制系统！），这是 Git 相对于更传统的源代码控制系统的主要优势。
例如，如果您正在使用 SVN 的代码库中修复错误或添加功能，标准做法是检查
使用 Git 或类似系统，您可以
这样做的优点是，如果您必须返回并重新修复错误，您仍然拥有该分支的本地副本。
有关详细信息，请参阅成功的 Git 分支模型等文章。
From my personal experience I would recommend looking at the new generation of 'Source Control Systems' that are called Distributed Version Control Systems. These are systems like Git (and I think Mercurial but I haven't used that.) that actaully store a full version control system locally and when you commit to the remote repository (push in git terms) you push the changes in your local version control system to the master version control system on the server.
Also Git is designed to make Branching a breeze. In systems like Subversion branching is not as easy but with Git Branching is the recommended practice of making changes. I have used Git, Subversion (SVN) and SourceSafe(the worst Source control System of the three by far!) and this is the major advantage of Git over more traditional Source Control Systems.
For Example if you are fixing a bug or adding a feature in a code base that uses SVN the standard practice would be to
With Git or Similar systems you would
The advantage of this is that if you have to go back and revist the bug fix you still have your local copy of that branch.
See articles like A Successful Git Branching Model for more info.