共享開發服務器上的Subversion

Question

我正在考慮在我的工作中實現源代碼管理。理想情況下，我想使用Subversion，因爲它似乎是目前的首選工具。但是，我似乎碰到了一堵磚牆，因爲對於我們所有的開發人員來說，在當地環境中工作並不實際。我們使用Coldfusion進行網絡開發，並使用共享的開發服務器。對文件所做的更改可以在瀏覽器中快速刷新。

我們公司擁有超過100個站點，我們的開發服務器鏡像所有這些生產站點。我們經常需要對這100箇中的1個進行快速調整，測試並快速上傳到生產環境。如果我們不得不在本地下載一個給定的網站，在我們的本地網絡服務器上進行設置，這些小的更改將變成耗時的任務。另外，通常撰稿人和技術較差的人會想要進入HTML頁面並更改副本。這在我們當前的共享服務器設置中很簡單。

很久以前，我們使用了一個名爲NGSource的源代碼控制，當您將一個項目簽入存儲庫時，它將文件權限更改爲只讀。我們會將文件檢查到共享的開發者服務器，並且會改變讀取和寫入的權限。我們都會檢查存儲庫，以確保有人不在我們認爲需要處理的文件上工作。這運作良好，可以向撰稿人解釋。問題是NGsource客戶很慢，據我所知，他們可能會停業。

那麼有沒有辦法在簽入和簽出Subversion時實現文件權限的更改？如果沒有，是否有更好的開源解決方案？在共享環境中開發並跳過本地開發是否糟糕？

Answer 1

您可以使用'svn lock'[1]來確保沒有其他人能夠編輯您當前正在處理的文件。

[1] http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html

Answer 2

你能解釋一下你爲什麼需要「只讀」模式的文件嗎？正如你所描述的那樣，你可以在生產網站上維護一個工作副本。因此開發人員或撰稿人只需連接到站點，編輯它並直接從生產站點提交更改。

Answer 3

我是一家開發公司的版本控制管理器，它可以製作和維護Web應用程序和網站，但幾乎不像您的那麼多。我瞭解在100多個網站正常工作（如果有的話）n開發人員/版權所有者的當地信息箱中的複雜性，並且認爲這是一個合法的原因，因爲它們不會在本地簽到。

關於我們的流程

在我們的過程，也就是本地製造的第一個去的地方是對客戶數據的合理表示審覈登臺環境的任何變化，那麼當它被認爲是好的它終於轉移到生產環境。我們不會在生產安裝版本的代碼庫，這是因爲：

1. 文件系統開銷： SVN保持的東西等同於一個簽出目錄兩次的信息。這就是爲什麼你可以在不連接到服務器的情況下進行區分和還原的原因。
2. 安全性：擁有額外的.svn目錄只是另一個攻擊向量。這可以得到補償，但收益是否超過成本？對我們來說，不。

相反，我們使用RepliWEb這樣的工具將代碼庫從Staging複製到Production。

關於您可能的過程

請問，如果你有一個登臺環境與配置的所有100多個站點，運行它的工作，和源代碼控制之下？這是所有開發人員和版權所有人用來進行修改的環境，然後他們會提交。當修改被認爲是好的時候，像RepliWeb這樣的工具可以將Staging中的版本（不包含.svn目錄）轉移到Production中。如果貴公司的文件系統開銷和安全風險可以忽略不計，那麼RepliWeb將被取代，只需簡單地在生產環境中清理檢查站點（確保刪除任何以前的工件）即可。

我希望這會有所幫助。

謝謝
扎卡里

Answer 4

我能想象你的痛苦，但你並沒有告訴我們什麼地方錯了你目前的程序）。畢竟，它「不會修復，如果它不壞」。僅僅因爲每個人都使用SVN/GIT等，所以沒有人會爲你服務。

我們在這裏有類似的要求，但幸運的是仍然有設置本地簽出和本地網絡服務器，有些人在提交之前使用。這是推薦的方式。 對於通過samba或nfs進行安裝的其他人來說，有一個共享的開發環境。但仍然每個人都擁有自己的工作空間。 工作在前臺的人很多，並且檢查了不重要的更改，他們使用web界面調用數據中心或目標（客戶端）系統上的主登臺系統上的svn更新。當事情破裂時，這是他們的自由裁量權和錯誤。當然，這些步驟可以完全自動化使用svn鉤子。

我們的結果迄今爲止是可以接受的。

如果您認爲個人工作空間的開銷對您的業務案例來說太高，那麼我認識的任何源代碼控制都可以幫助您。你仍然可以鎖定svn中的文件，以便人們無法檢查更改，直到它解鎖，但這是非常非常的1990年...

畢竟什麼是源代碼管理的目標？一些我能想到的：

• Paralell發展與許多人
• 隔離的穩定和不穩定的代碼
• 透明度和回滾能力

當你有沒有一個個人工作空間的概念，一個「用戶」代替匿名的「團隊」來檢查文件，大多數源代碼管理功能自然不適合你。

也許你可以在你的coldfusion服務器上有子文件夾？通過從源代碼管理服務器自動更新所有這些開銷來減少個人工作區管理開銷（通常我不推薦）？

如果可能，您需要先離開「我們在服務器上編輯」習慣，然後再考慮源代碼控制。另一種方式圓將是複雜;）

Ç

Answer 5

在我們公司，我們已經非常相似的情況 - 不是開發更多的項目。所以所有的項目都在開發服務器上，開發人員可以在其上輕鬆開展工作。通常只有一個開發人員在給定時間在一個項目上工作。但開發人員來了，離開，休假，踢球等，所以我們需要快速切換項目。 但理想情況下使用版本控制，以擺脫對改變某些東西的恐懼，以及版本控制帶來的所有其他好處。

像svn，csv，p4等集中版本控件不適合這種解決方案。只能使用分佈式版本控制。

我們正要測試一些分佈式版本控制，比如Mercurial或GIT，它似乎是唯一適合在所描述的環境中工作的版本控制器，即使它們可能不是爲這種情況而開發的。

但是由於開發人員沒有個人空間，我們將無法使用版本控制的所有方面。開發者將需要把他們的名字int checkin note。但至少比什麼都沒有。

我做了一些研究，這裏是我發現了一些有趣的聯繫：

How to use version control on a remote development server?

Version control has me stumped

https://www.mercurial-scm.org/wiki/TortoiseHg

http://git-scm.com/