一家從事網絡開發業務的公司一直使用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