一家从事网络开发业务的公司一直使用FTP作为代码库。几年来一直没有应用版本控制。遵循什么策略从FTP迁移到版本控制？
当他们的代码和库迁移到版本控制系统（我计划使用SVN，这是我熟悉的SVN用户）。
我的计划（现在是SVN安装）是先创建一个目录。开发人员完全不知道版本控制，我可能会在这里使用类似问题的输入，如Converting a development team from FTP to a Versioning System。然后让开发人员在开始将实际代码，架构和其他配置项目置于版本控制之前播放（创建/提交/结帐/更新/回复）约一周。
除了培训开发人员 - 我应该遵循什么策略，以及我应该面对哪些陷阱？想到的一点是需要脚本在分支时剥离.svn条目。
p.s.主持人请把这个放在社区wiki下面吗？我相当肯定，对此没有“一个完美的答案”。同时这个话题可能为别人带来价值。
在您可以说服从未使用过版本控制软件的开发人员之前，您必须准备好回答每问题，担心和怀疑他们会有。你会被如下问题淹没：
您接受的问题的答案是一个好的开始。您需要演示：
你不能只安装版本控制（Subversion或其他），并且每天都会调用它。人们会回到旧的方式，因为它更容易（可能不会，这只是他们习惯的）。您需要掌握源&配置管理和的设计流程以支持您的工作流程以及您的跟踪要求。
你至少有两个完全独立和不同的环境（dev &生产），最好是三个（dev，分期&生产），对不对？如果没有，从那里开始。 人们不应该随意更改现场网站！如果可能的话，开发人员应该能够在他们的工作站上正确运行他们的项目，以便他们可以在登记之前进行测试。
您的应用程序应该完全自行配置。也就是说，每次将它们部署到给定环境时，都不需要手动摆弄它们。部署应该或多或少地“放手”或至少脚本化。完成设置后，您需要自己的脚本，持续集成系统或两者的组合来处理部署。
您可以use a post-commit hook script在开发环境中更新您的网站。因此，只要开发人员提交了更改，他们就会到开发站点去查看。
我自己的设置是这样的：
我的CCNET配置也存储在Subversion中，并通过CCNET部署，因此我们不必直接触摸服务器上的文件 - 我们更新它们，提交并触发一个“构建”，它将更新配置到该服务器。
所有的标签为我提供了什么？
其他工具，如RedGate的部署管理器，可以使这更加自动化。
为了使所有这些工作，你需要有一个坚实的，一致同意的过程，每个人都遵循。强有力的separation of duties也是有益的 - 你的开发人员不应该部署，并且你的管理员不应该在代码中混淆。 OK，所以你已经把所有这些都设置好了，每个人（包括管理人员！）表示他们在船上，接下来是什么？
撤消所有开发人员对非开发服务器的访问权限。没有更多的FTP，没有更多的外壳，没有。也许只读访问某些日志，如果你有它们的话。
他们会抱怨。他们会畏缩。他们会生你的气。 “你把我所有的通道都拿走了！” “你挡我的路！” “这会让我花10倍的时间来做一个简单的改变！” “你是个怪物！” “你让撒旦看起来像个好人！”
没关系。只要有“更简单的方法”，正确的方法将被忽略。这就是为什么你需要管理和观察你的背部。
由于实时流量负载过多，第一次出现问题并导致数据库服务器关闭时，您将恢复到以前版本的应用程序，并且事情将在5分钟内恢复正常。你会成为英雄。
你说你需要“在分支之前去掉.svn条目”是我的一个担心。要么你描述你的过程不好，要么你做错了什么。
编辑：只记得别的东西。你的存储库有一个备份策略，对吧？如果没有，并且驱动器因数据丢失而失败，那么所有内容都将被归咎于你& Subversion，而不是在失败的硬件上（尽管硬件故障可能发生在任何地方）。
我在将新团队与SCM加速时遇到的最大问题是滥用导出/导入来“撤消”更改。初学者通常会重新导入一个文件，而不是利用反向合并（通常是因为我的经验缺乏培训）。这种“重新导入”而不是“反向合并”很笨拙，给用户带来不好的体验;导致'我们没有FTP这些问题！'投诉。 – Josh