我正在考慮外包一些開發工作,並希望發放SVN憑據,而不是授予對我使用的服務器的訪問權限。有沒有辦法創建一個沒有訪問日誌的SVN用戶?
但是,我對此有點不舒服,並想知道是否有可能阻止特定用戶運行svn log
並能夠查看文件歷史記錄。
所有他們真正需要的是基於可能創造path-based-authorization您可以限制訪問您的存儲庫的特定區域,這意味着,並非所有的歷史都是可讀只有在你給的路徑co
,ci
和diff
我正在考慮外包一些開發工作,並希望發放SVN憑據,而不是授予對我使用的服務器的訪問權限。有沒有辦法創建一個沒有訪問日誌的SVN用戶?
但是,我對此有點不舒服,並想知道是否有可能阻止特定用戶運行svn log
並能夠查看文件歷史記錄。
所有他們真正需要的是基於可能創造path-based-authorization您可以限制訪問您的存儲庫的特定區域,這意味着,並非所有的歷史都是可讀只有在你給的路徑co
,ci
和diff
進入。我認爲這應該沒問題。否則,你真的需要做一個副本,並且必須複製這些存儲庫之間的變化,這在SVN中不是一件簡單的工作。
簡短的回答
號
龍答案
所有的標準方法的工作或更高的水平,比單SVN命令(操作共同讀/寫權限 )或更低級別(使用單獨的DAV-命令,集合,其被翻譯成單個svn命令)
這裏khmarbaise不得不錯過了一個
思考和考慮
如果你能建立DAV-SVN命令映射表(使用Apache日誌和手),並確認,即在啓用DAV-層和禁止的svn-commands在DAV端沒有交集,只能禁用「bad」dav-commands。但我認爲,它們都有交叉點(未經測試!)。從另一方面來看,如果您只希望限制從某個時間點訪問較早的歷史記錄(並非完全禁用使用命令,而我一味認爲不可能),那麼您可以將外包商的工作空間拆分爲單獨的樹,其使用路徑基於訪問控制。
這裏khmarbaise有二小姐
,因爲他記得只有約1)獨立2)無關的信息庫,而至少有2種選擇:
在兩種方案中用戶的日誌將在他的空間停在第一個版本(由於缺少較舊的修訂或漏抄之前訪問歷史)通過合併,雙向同步仍可能有足夠的訪問權限級別的用戶。
該方法的問題在於其他一些命令也需要訪問歷史記錄(特別是合併)......此外,在DAV級別上執行該操作的設置配置起來會更復雜。還有一點是,你不知道OP是否通過http ...與svn級別工作,這是行不通的。基於路徑的授權將適用於http(s)和svn協議! – khmarbaise 2012-03-28 19:44:50
此外,真的很高興責怪人是這樣的。 – khmarbaise 2012-03-28 19:46:34
我不會這麼想,但這是一個有趣的問題!一個解決方法可能是從沒有歷史記錄的出口創建一個新的存儲庫,併爲他們提供相應的工作方式 - 除非我想不出一種將他們的個人提交合併到你的工作中的簡單方法,或者將你自己的工作合併在此期間 - 或者甚至可能是您的新分支,並打破「複製來的」元數據,這樣SVN就不會認爲它背後有任何歷史。 – Rup 2012-03-28 16:04:55