我有机会向我的老板正式介绍任何有利于公司的事情。我的想法是在我的工作场所采用源代码控制。我一直在使用 Mercurial 来管理我自己的工作项目，但是团队的其他成员没有正式的源代码控制系统。不幸的是，我不太擅长提出想法。
那么，你们能告诉我为什么开发人员必须使用源代码控制吗？此外，您为什么要选择除Visual SourceSafe 之外的任何工具？我没有使用 VSS 的经验，但他可能会问我们为什么不只使用 Microsoft 的工具。
我想在这里听听许多聪明的程序员的意见！我的首选选项是 SVN 或 mercurial。两者似乎都对它们的 Windows 版本有很好的支持，而且都没有 CVS 过时。另外，作为一个自称开源的弟子，我更愿意推荐一个开源工具。:)
谢谢！
编辑：简而言之，一般来说，其他开发人员的当前做法是复制文件夹，用日期标记，也许自己记录。你得到图片。如果我的老板说“如果它有效，为什么要修复它？”
让我们比较两个示例，一个使用源代码控制的开发环境，一个不使用。
场景 1：请求、完成并推出一个项目
A + B) 程序员在内部开发项目，完成后，将其推出测试，然后交付给客户（无论是谁）
大体上没太大区别
场景 2：项目发布后，客户决定不想要功能 X
A + B）开发人员删除客户不想要的代码，测试和交付。
再次，没有太大区别。
场景 3：两周后，客户决定他们确实想要功能 X
A) 开发人员将他们在 2 中取出的代码重新集成到正常的开发树中，进行测试和交付。
B) 开发人员在他们的个人机器、文件服务器和备份上搜索旧代码。如果他们找到代码，他们必须手动重新插入每个文件。如果他们不这样做，他们可能不得不重新编码整个功能。
很容易得到你出于某种原因取出的旧代码
场景4：系统中有一个奇怪的错误，一个函数应该返回一个布尔结果，但总是返回false。两周前不是这样的。
A) 开发人员检查所有旧版本的软件，并发现 return false 指令不在正确的范围内——它在循环内部而不是外部执行。
B) 开发人员花费数周时间试图找出问题所在。最终，他们注意到返回错误的线路，并修复它。没有源代码控制意味着他们必须检查每个执行的文件，而不是找出它工作时和现在的差异。
场景 5：有人破坏了构建。它通过了测试，几周后才被发现。
A）团队检查提交历史，找出谁破坏了构建，让那个人修复它并购买团队晚餐。
B) 团队要回溯整个项目才能找到错误，但无法弄清楚是谁把那个代码放进去的。开发人员互相指责，团队动态失败。
很容易看出谁犯了什么、什么时候犯了、为什么犯了。
使用源代码控制，因为您和您的团队都不是完美的。源代码控制的主要功能是确保您拥有完整的开发过程历史记录。有了这个记录，您就可以自信地使用“实验”版本进行分支，知道如果实验失败，您可以备份到较早的版本。
此外，像 svn 这样好的源代码控制系统将允许多个开发人员在同一个文件上工作，并提供强大的工具来协调每个人引入的差异。
简单地说——这样你就有了代码的真实历史——调查更改（错误的原因）、恢复到版本、审计等。备份是不够的——你只需要一份当前图片的副本。曾经更改过文件并希望您能记住您所做的事情吗？
由于这些原因，您必须使用源代码控制
1）您可以回滚到任何版本
2) 不同的开发人员可以处理相同的文件
3) 所有开发人员都可以访问相同的代码库
4）您可以跟踪更改
5）您可以回滚不起作用的更改
6) 源代码控制是持续集成的基础，极大地帮助了 TDD
7）如果你不使用源代码控制，你会慢慢发疯，因为文件丢失/覆盖，没有任何效果
VSS 并不是最糟糕的 SCC 应用程序，我使用了多年并且越来越讨厌它，但它确实有效，很简单，而且很多人都知道它。
这是一个简单的现实生活示例。
几年前，我的老板说，“功能 XYZ 以前可以工作，现在不行。没有人知道发生了什么。你能解决它吗？”
现在我以前从未使用过功能 XYZ。因此，修复它需要花很多时间试图弄清楚它的作用。
但是我们有源代码控制！所以我这样做：
我一直在做这个二分搜索，直到最终我遇到了改变：版本 145（我们会说）有这个功能工作，但版本 146 已经坏了。然后我只是对这两个版本进行了比较，看看有什么变化。原来我们的技术负责人 ( sigh ) 签入了更改功能的代码，但也引入了破坏功能 XYZ 的副作用。
所以我消除了副作用，测试了……你瞧，功能 XYZ 再次起作用了。
如果没有源代码控制，您将永远无法做到这一点。您将不得不四处奔波，改变一件事或另一件事，希望能神奇地找到使功能 XYZ 再次起作用的东西。
使用源代码控制，您只需通过版本进行测试，查明导致问题的确切代码并修复它。
在我看来，大多数人已经涵盖了源代码控制的主要功能，但忽略了其中一个最大的优点。这些是：
分支机构
如果没有源代码存储库，就不可能为特定目的创建代码的分支（或副本/流/等）。无法创建和合并分支是使 VSS 无法成为真正的源代码控制系统的最大原因之一。分支机构的一些目的包括：
错误修复
有时您需要解决错误并在远离代码的主线或主干版本的地方进行。这可能是为了解决测试环境中的问题或任何数量的原因。如果你有一个版本控制工具，你应该能够轻松地创建一个新分支（VSS 很讨厌的东西）来修复错误，并能够在必要时将其合并回主线代码
维护版本
这可能与错误修复大致相同，但在代码发布到生产环境后完成。示例是修订包、服务版本等。同样，您希望能够在必要时将更改合并回主干
新功能
有时您需要在维护当前代码的同时开始开发新版本。例如，您发布并维护 v1.0，但需要在维护 v1.0 的同时开始 v2.0 的工作。分支有助于解决这种情况
标记/标签
源代码控制系统所做的另一件事是在特定时间点对源代码进行快照。这些在 VSS 中称为标签，在 subversion 中称为标签等。通过定期创建这些并将它们链接到项目中的某个重要里程碑，就可以确定代码在不同版本之间的确切更改。这对审计员来说很重要，但对于追踪问题的来源/范围也很重要。VSS 在这里也失败了，因为 VSS 只对文件进行版本控制，而不是目录。这意味着如果您重命名/移动/删除存储库中的文件或目录，就不可能重新创建系统的先前版本（重构时会发生很多事情）。像 Subversion 这样好的源代码控制系统就是这样做的。
Microsoft (MSDN) 有一篇关于源代码控制的好处的好文章。
http://msdn.microsoft.com/en-us/library/ms173539.aspx
关于优缺点，这里也有很多很好的问题。
用过之后你对 git 的优缺点是什么？
Subversion 非常流行，但 Git 将成为源代码控制领域的“下一件大事”。
我建议使用 SVN，因为：
我建议不要使用 VSS -出于更多原因，请参阅此页面： http ://www.highprogrammer.com/alan/windev/sourcesafe.html。
如果当前的过程是复制一个文件夹并给它一个日期，那不是为了让您获得某种开发历史，那基本上不是一种简单的源代码控制形式吗？
因此，要回答有关源代码控制的任何批评，您已经在这样做了。现在您只需要指出当前系统中的弱点并提出更好的建议。当人们真正考虑了在开发过程中可能发生的许多复杂场景并开发了让他们处理它们的工具时，为什么还要重新发明轮子。
您当前所做的事情非常脆弱，如果出现任何复杂的情况都会失败，此时您将不得不花费大量精力来研究如何做工具已经做的事情。VSS 比您正在做的更好，但没有 SVN、git 或 mercurial 所具有的非常有用的约定，这些约定允许多个项目以井井有条的方式生活在一起——我说的是分支、标签和合并，两者都是其中很脆弱，基本上是vss下的噩梦。
SVN 确实有 Visual Studio 的插件。有些是免费的。但我发现 tortoise-svn 让其他任何东西都黯然失色。我发现插件的唯一好处是新文件会自动添加到 svn。
因此，您当前系统的弱点：
这可能足以继续下去，可以做得更多。
在任何情况下，拥有一些版本控制系统都会有所帮助：
如果每个版本控制系统想要称自己为版本控制，它必须完美执行的最基本任务是能够返回到项目的指定版本。如果你把事情搞砸了，你可以回到以前的版本。您可以检查一些以前的版本以检查它是如何完成的（例如在重构之前，或者在删除某些代码/文件之前它是如何完成的）。
与简单地保存具有指定日期的备份副本相比，版本控制系统占用的磁盘空间要少得多，因为它们使用增量化（仅存储与先前版本的差异）和压缩。通常备份系统是存储项目的最后 N 个版本的方法，有时 N=1（仅以前的版本），而版本控制系统 (VCS) 存储项目的所有历史记录。在删除最后一个版本后了解 Murphy 一段时间，您会意识到那是您想要检查的版本。
此外，回到上一个版本是简单和自动化的。您还可以检查单个文件在某个过去版本中的外观，并且您可以获得当前状态和某个过去版本之间的差异（以差异格式）。您还可以标记（或“标签”）版本，因此您不仅可以按日期或当前版本的第n个版本来引用过去的版本，还可以通过符号名称来引用过去的版本，例如v1.2or v1.2-rc0。
使用版本控制系统，您可以检查历史记录以提醒您为什么（以及如何）某些代码（给定文件的某些部分）到达当前状态。大多数 VCS 允许检查文件的逐行历史记录，即注释文件的每一行何时更改、在什么提交中以及由谁更改（命令名为annotate，blame或praise取决于 VCS）。在某些 VCS 中，您可以搜索历史以查找引入给定代码片段的版本（修订版）（例如，在 Git 中称为“pickaxe search”，VCS 之一）。
要使此功能真正有用，您必须保持一定的纪律：您应该描述每个新版本（每个新修订/每个新提交）并写下进行更改的原因。这样的描述（提交消息）非常有用，但它在备份系统中并没有自然的位置。
如果您不是唯一的开发人员，此功能当然会更加有用...
使用版本控制系统允许在代码中查找错误的替代方法，即通过搜索历史来查找引入错误的版本：bisectiong history。当您找到引入错误的修订版时，您将有有限的（在最好的情况下：非常有限）区域来搜索错误，因为错误必须在最后一个工作版本和第一个有错误的版本之间的差异。此外，您还会有更改的描述（提交消息）以提醒您想要做什么。此功能有时也称为差异调试。现代版本控制系统 (VCS) 支持自动化（或半自动）通过将历史一分为二（将历史分成两半，查找包含错误的部分，重复直到找到单个负责版本）以bisect（或类似）命令的形式搜索历史。
要使此功能真正有用，您必须遵守一些纪律：您应该提交（保存更改/将给定状态放入版本控制系统以记住）单个更改，只处理一个功能，与以前的版本只有很小的区别；即经常提交。
大多数版本控制系统都提供了各种钩子，例如允许自动测试或自动构建产品......或者只是提醒您不遵循编码标准（编码指南）。
版本控制系统允许创建多个替代的并行开发线，称为分支（或流或视图）。常见的情况是有开发分支，即有单独的分支用于不稳定的开发（测试新功能），单独的分支用于稳定（主要，主干）版本，这是（或应该是）当前工作版本，以及一个单独的维护（修复） ) 分支。
拥有维护分支允许您进行错误修复并生成服务包/次要版本，并对某些已发布版本进行更正，而无需担心新开发的干扰。稍后您可以将维护分支合并到稳定分支中，或者从维护分支中选择 bigfix 到稳定分支和开发分支中（如果进一步/其他开发没有独立修复错误）。
现代 VCS（这里现代意味着分支和合并分支都很容易）允许更进一步，即生成单独的分支来处理单独的功能（所谓的主题分支）。这允许您在使用一项功能和处理另一项功能之间进行切换（而不仅仅是从开发新功能切换到处理紧急请求的错误修复）。
如果您正在基于其他（通常是第三方）产品的来源开发产品，那么您确实应该使用供应商分支，以便能够轻松地将供应商的产品的新版本与您所做的更改集成。诚然，这不再是纯粹的“单一开发者”案例。
如果有多个开发人员在同一项目上工作，则使用版本控制系统会带来更多优势。VCS 允许并发（并行）开发，而不必担心有人会覆盖您的更改，或者不会考虑您的更改。当然，使用版本控制系统并不能代替通信。
在多开发人员的情况下，上述所有功能甚至更为重要：检查谁生成了给定的更改，谁最后更改了代码（也就是谁破坏了构建），发现代码中的错误不是仅由您编写的。
在你说任何话之前，找出你的公司为什么不使用源代码控制。
一旦您知道原因，就很容易想出源代码控制可以提供帮助的方案。
关于为什么你绝对应该拥有源代码控制的长时间讨论：
我对该线程的评论：
即使您自己在一个项目上工作，您也总是希望拥有某种源代码控制。
拥有更改历史对于能够在任何给定时间查看代码库的状态至关重要。回顾项目历史的原因有很多，从能够回滚错误的更改到为旧版本提供支持（当客户只想要补丁来修复错误而不是升级到新版本）软件。
没有某种源代码控制是纯粹的精神错乱。
就 VSS 而言 - 总比没有好。它绝对不是最好的源代码控制，而且它已经过时了，但事实上它继续为很多公司做这项工作。
如果您的老板决定坚持使用 Microsoft 工具，请选择 Team Foundation Server 而不是 VSS。这是一个比 VSS 更好的系统，并且它具有集成错误跟踪等不错的功能。
简单：如果代码不是源代码安全的，则它不存在
Subversion 是免费的，而且比 VSS 更好，但 VSS 绝对比没有更好。
从我这里拿走，VSS吹。这是带有历史记录的基本文件存储。什么都比VSS好，VSS总比没有好:)
那么，你们能告诉我为什么开发人员必须使用源代码控制吗？
源代码控制就像保险！你希望你永远不需要它，但很高兴你拥有它！
因为：
它将降低成本 - 与他们当前的临时方法相比，开发人员将不得不花费更少的时间检查一个真正的 VCS 中的项目。
它将保护组织的知识产权——这应该是任何软件公司最重要的考虑因素（除了数据......）。您为创建软件而付费 - 它不应该完全可以访问吗？
它将提供更快、更可靠和更直接的备份机制——所有 VCS 都内置了转储功能。这些往往比简单的文件副本更成熟。
它将充当开发人员之间的通信机制 - 根据版本控制系统，您可以使用评论/标签/签出状态来确定其他人是否在处理文件，是否已升级到生产，是否有相应的支持票号等
它简化了开发 - 比较文件版本以及其他机制的能力将对您的公司时期有益。
我真的很抱歉，但如果你真的不得不在开发环境中争论源代码控制的[形式化]，那么你就处于绝望的境地。如果你的老板确实需要说服源代码控制是一项值得的努力，那么你的老板根本不适合担任一群软件开发人员的经理。为了让某人有效地管理，他们至少需要对景观有基本的了解。我什至无法想象当你真的需要为一些值得争论和做演示的事情争论时会发生什么。
没有源代码控制的开发就像开车不停歇。你失去了进行无缝并发开发的能力，你失去了在工作副本中备份代码的能力，你失去了通过代码注释进行历史研究的能力，你失去了查看伴随离散更改的上下文和注释的好处，你只是输，期间。使用源代码控制是如此明显并且有如此多的好处，令人震惊的是你不得不证明它是合理的。
在工作中，我们使用颠覆，但一些开发人员（包括我自己）通过 git-svn 桥在本地使用 Git。对于个人工作，我使用 Git。
即使作为一个单独的开发人员，我也使用源代码控制。在现代软件开发环境中，我几乎想不出为什么不使用源代码控制的原因。更令人惊讶的是，您还没有它。这个问题让我印象深刻，就像房屋油漆工在问“我们为什么要使用梯子。你知道，梯子不能粉刷房子——刷子可以。”
为什么要做正式演讲？
假设团队规模至少为两个，做一个真实的例子：让两个（或更多，越多越好）人获取代码，进行更改，并展示如何使用任何非源代码控制来集成所有这些更改表示你使用。
然后使用源代码管理执行相同的场景。
使用源代码管理节省的时间和痛苦将不言而喻。
坚持底线，解释它与金钱的关系，你的老板可能会听。
如果你只是一个程序员，我想说的主要论点是减少你浪费时间（以及金钱）修复简单错误、试图回滚变成错误想法的代码等的机会。
如果您是不止一个程序员，那么上述内容会重复两次，而且这是能够在同一个代码库上一起工作而不会浪费更多时间等待彼此的唯一明智的方式，
Visual Source safe 总比没有好，但有几乎在各个方面都更好的免费选项。如果你的老板需要一个演示来理解为什么源代码控制是必不可少的，他可能不会关心你使用什么工具，一旦他得到启发。你有使用其他工具的经验而不是再次使用 vss 与底线有关，所以这可能就足够了。
说服管理层在 SCCS 上投入时间的最简单方法是专注于备份和归档。通过使用 Subversion (SVN) 之类的东西，您可以立即将任何项目恢复到任何时间点。无需有人查看备份磁带或担心在钝目录结构中跟踪多个版本。
显然还有许多其他优势（即 2 个人同时处理同一个文件），但备份是多年前我的公司迅速卖掉的东西。
我们使用版本控制的主要原因是一致性。
如果项目不一致，就会出现问题，代码就会丢失。
确保你已经为团队的其他成员买单。也许您可以在它们上测试您的演示文稿？希望他们也看到了需求。
很高兴看到自下而上的良好实践。如果它来自他们自己的一个人而不是某些管理任务，也许每个人都更有可能采用这种做法。
为了避免类似的事情
"Hey! What happens ? It worked yesterday."
其他人在其他地方提到了源代码控制的具体好处，但我想明确解决问题的“VSS”部分。
如果您的老板想使用 Microsoft 工具，Team Foundation Server 与 Team Suite 是一个非常好的组合。它还包括其他工具，例如错误跟踪、文档和报告功能，这是一个很好的平台，可以在以后改进您的流程。我们对我工作的地方非常满意，我的同事告诉我关于 VSS 的恐怖故事。
记住 TFS 作为对“Microsoft 工具”问题的回应。