一家从事 Web 开发业务的公司一直使用 FTP 作为代码存储库。几年来一直没有应用版本控制。
在将他们的代码和库迁移到版本控制系统时（我计划使用 SVN，这是我作为 SVN 用户所熟悉的）。
我的计划（现在已经安装了 SVN）是首先创建一个目录。开发人员完全不知道版本控制，我可能会在类似的问题上使用这里的输入，例如将开发团队从 FTP 转换为版本控制系统。然后让开发人员玩（创建/提交/签出/更新/恢复）大约一周，然后开始将实际代码、模式和其他配置项置于版本控制之下。
除了培训开发人员——我应该遵循什么策略，我应该面临哪些陷阱？想到的一个是在分支时需要一个脚本来去除 .svn 条目。
ps 版主可以把这个放在社区维基下吗？我相当肯定对此没有“一个完美的答案”。同时，该主题可能对其他人具有价值。
在说服从未使用过版本控制软件的开发人员之前，您必须准备好回答他们会遇到的每一个问题、担忧和怀疑。你会被以下问题淹没：
您链接的问题的公认答案是一个好的开始。你需要证明：
您不能只安装版本控制（Subversion 或其他）并收工。人们会回到他们的旧方式，因为它更容易（可能不是，这只是他们习惯的方式）。您需要掌握源代码和配置管理以及设计流程以支持您的工作流程以及您的跟踪要求。
您至少有两个完全独立且不同的环境（开发和生产），最好是三个（开发、登台和生产），对吧？如果没有，从那里开始。人们不应该随意更改实时网站！如果可能的话，开发人员应该能够直接从他们的工作站运行他们的项目，这样他们就可以在签入之前进行测试。
您的应用程序应该是完全自配置的。也就是说，每次将它们部署到给定环境中时，您都不需要手动调整它们。部署应该或多或少地“放手”或至少是脚本化的。设置完成后，您将需要自己的脚本、持续集成系统或两者的组合来处理部署。
您可以使用提交后挂钩脚本在开发环境中更新您的网站。因此，一旦开发人员提交了他的更改，他们就会去开发站点进行查看。
因此，我自己的设置是：
我的 CCNET 配置也存储在 Subversion 中并通过 CCNET 部署，因此我们不必直接接触服务器上的文件——我们更新它们、提交并触发“构建”，将更新的配置下拉到该服务器。
所有标签都为我提供了什么？
其他工具，例如 RedGate 的部署管理器，可以使这更加自动化。
为了使所有这些工作，您需要有一个每个人都遵循的可靠的、商定的流程。严格的职责分离也是有益的——你的开发人员不应该部署，你的管理员不应该在代码中乱七八糟。
好的，所以你已经设置了所有这些，每个人（包括管理层！）都说他们在船上，下一步是什么？
撤销所有开发人员对非开发服务器的访问权限。不再有 FTP，不再有 shell，什么都没有。如果您在那里拥有某些日志，则可能是对某些日志的只读访问权限。
他们会发牢骚。他们会畏缩。他们会生你的气。“你夺走了我所有的访问权限！” “你妨碍我了！” “这将花费我 10 倍的时间来进行简单的更改！” “你是怪物！” “你让撒旦看起来像个好人！”
没关系。只要有“更简单的方法”，正确的方法就会被忽略。这就是为什么您需要在船上进行管理并注意背后的原因。
当某些东西第一次投入生产并因为实时流量负载过多而导致数据库服务器停机时，您将恢复到应用程序的先前版本，并且一切将在 5 分钟内恢复正常。你会成为英雄。
你说你需要“在分支之前剥离 .svn 条目”让我担心。要么你描述你的过程很糟糕，要么你做错了什么。
编辑：只是想起了别的东西。您已经为存储库制定了备份策略，对吗？如果没有，并且驱动器因数据丢失而发生故障，那么一切都将归咎于您和 Subversion，而不是故障硬件（尽管硬件故障可能发生在任何地方）。