文件系統上的Mercurial remotes而不是http服務器

4

我目前正在從svn遷移到mercurial。我的需求很簡單，我需要通過公司內部網的源代碼控制。我在任何地方都可以看到用於通過IIS設置遠程配置的示例。當我只能在服務器上共享時，我只是看不到這一點。文件系統上的Mercurial remotes而不是http服務器

我還可以使用NTFS權限在repos上設置授權和身份驗證嗎？

我錯過了什麼嗎？

謝謝

來源

2011-10-18 jfabre

3

將存儲庫放在文件共享上是有效的，但這不是Mercurial團隊推薦的方式。

見Publishing Repositories在HG維基「共享磁盤」的一部分：

一般只限於企業內部，一般不建議由於與網絡文件系統的可靠性一般問題

確保檢查出Chris Becke's answer，因爲他指出了另一個有效的缺點（有寫訪問權限的人從網絡共享中刪除東西，無論是否有意）。

如果您知道（並且可以忍受）這些事情，將存儲庫放在網絡共享上無疑是最簡單的安裝方式。

我個人的經驗是，只要Windows共享位於「真正的」Windows計算機上，它就能完美運行。
在工作中，我們在真正的Windows服務器上使用了一個沒有問題的共享，但是在家裏我遇到了一個NAS問題（它的行爲像Windows共享，但實際上在Linux上運行）。
你可以在這裏閱讀更多關於我的經驗：
Can you 'push' to network share using Mercurial on 64bit Windows 7?

來源

2011-10-18 22:30:29

+1

良好的鏈接，很好的答案，謝謝。 – jfabre

+0

主要問題是，如果您失去網絡連接，或者服務器/共享存在鎖定問題（如使用該NAS），那麼如果在推送過程中出現問題，則不需要執行清理步驟。不能保證存儲庫仍然有效。當然，在本地或服務器上都沒有100％的保證，但是當出現問題時，它可以正常運行。 –

+0

是的，我知道。我們在工作中從來沒有遇到過問題（在使用HG近兩年後），但我知道它可能會在任何時候發生。問題是，託管存儲庫的所有其他方式似乎都很複雜，我從來沒有時間把它放在它的周圍，而將存儲庫放在網絡共享上很容易，**只是起作用**（是的，以後可能會出現一些問題，但起初它只是起作用！）。不幸的是，我們必須在工作中自己進行託管（對於我現在使用Bitbucket的私人項目，但在外部託管我們的代碼的工作不是一種選擇）。 –

2

有很多理由喜歡，好了，任何事情可寫文件共享。

從本質上來說，有人可以通過網絡方法進行推送的能力有限。另一方面，讀/寫共享對於推送是必要的，但也允許用戶刪除整個回購，歷史和所有。

即使沒有調用惡意的意圖，人們（或流氓軟件代理）已知道導航到隨機網絡共享，並意外地將文件拖到它不屬於的地方。

鎖定電腦的最佳理由不是因爲您的同事發現使用解鎖的電子郵件帳戶將色情片發送給HR有趣，而是因爲它令人驚訝，清潔女工可以用抹布和鍵盤做什麼。在掃描工作組中的所有共享時，音樂庫應用程序可以找到什麼也令人驚訝，並且仔細地「移動」並編錄到某個庫中。

來源

2011-10-18 20:42:24

+0

如果我執行權限什麼拒絕任何刪除根目錄和.hg/*的？此外，只有開發組將被允許在存儲庫上讀/寫。遠程回購也將由每個本地回購+真實備份進行備份。所以，我並不是真的在這裏看到一個大問題。 – jfabre

+0

你是對的，只有開發者才能訪問共享，操縱的機會很小。我們也是這樣做的，它的工作原理。但即使開發人員都是技術人員，並且知道他們在做什麼：正如克里斯在他的回答中指出的那樣，有人偶然將文件夾拖到其他地方的機會總是存在**。 –

文件系統上的Mercurial remotes而不是http服務器

回答

相關問題