什麼樣的工具和程序，你會推薦別人或自己使用，以幫助簡化以下sceanario：（我知道它的一個漫長的，但任何幫助表示讚賞）工具和方法
我在一個團隊，有一個電子商務應用工作我們在我們公司發展。它是一個合理標準的LAMP應用程序，我們一直在開發和關閉約3年。我們在測試領域開發應用程序，在這裏我們添加新功能並修復錯誤等。我們的錯誤跟蹤和功能開發全部在託管的顛覆解決方案（unfuddle.com）中進行管理。當錯誤被報告時，我們在測試域上做出這些修復，然後當我們很高興錯誤已被修復時，將修改提交給svn。我們按照相同的程序添加了新功能。
值得指出的是我們的服務器系統和應用程序的總體架構。每次開發新功能時，我們都會使用我們的應用程序（始終是我們控制的服務器）將此更新推出到所有網站。使用我們系統的每個站點本質上都使用95％的代碼庫中完全相同的文件。我們在每個站點中都有幾個文件夾，其中包含定製到該站點的文件--css文件/圖像等。除此之外，每個站點之間的差異由每個站點數據庫中的各種配置設置定義。
這會影響到實際的部署本身。當我們準備推出某種更新時，我們會在測試站點所在的服務器上運行一個命令。這會執行一個複製命令（cp -fru/testsite// othersite /），並通過每個基於修改日期更新文件的vhost force。我們託管的每臺附加服務器都有一個虛擬主機，用於rsync生產代碼庫，然後我們在該服務器上的所有站點上重複複製過程。在此過程中，我們移出不想被覆蓋的文件，並在複製完成後將其移回。我們的部署腳本執行許多其他功能，例如應用SQL命令來更改每個數據庫，添加字段/新表格等。
我們越來越擔心我們的流程不夠穩定，不容錯誤，也是有點蠻力的方法。我們也意識到我們並沒有充分利用顛覆，因爲我們有一個職位，即在不使用分支或標籤的情況下，開發新功能會阻止我們推出重要的錯誤修復。這似乎也是錯誤的，我們在我們的服務器上有很多文件的複製。我們也無法輕鬆執行我們剛剛推出的功能。我們在每次推出之前都會執行diff操作，以便我們可以獲取將要更改的文件列表，以便我們知道之後發生了什麼變化，但回滾過程仍然存在問題。就數據庫而言，我已經開始關注dbdeploy作爲一個潛在的解決方案。但我們真正想要的是關於如何改進文件管理和部署的一般指導。理想情況下，我們希望文件管理與我們的存儲庫更緊密地聯繫起來，因此推出/回滾將更多地連接到svn。就像使用導出命令來確保站點文件與回購文件一樣。如果解決方案也可能會停止我們的服務器周圍的文件複製，那也是一件好事。
忽略我們目前的方法，聽到其他人如何解決同樣的問題真的很好。
總結...
是什麼使跨多個服務器上的文件的最好方法保持同步的SVN？
我們應該如何防止文件複製？符號鏈接/其他東西？
我們應該如何構建我們的回購，以便我們可以開發新功能並修復舊功能？
我們應該如何觸發rollouts/rollback？
在此先感謝。