如何驗證Subversion的工作副本

我有一個Subversion的工作副本，至少有一個丟失的文件（修復樹衝突時刪除了本地副本）。這很有趣，因爲該文件是版本化的，它出現在版本庫中，樹的衝突解決方案是100％本地的（它發生在更新上，之後我沒有提交），我運行了多次「svn cleanup」，但沒有一個Subversion客戶端（命令行svn和TortoiseSVN）可以檢測到工作副本已損壞。甚至還沒有恢復所有的改變文件回來。如何驗證Subversion的工作副本

我會像往常一樣修復它（在其他地方重新結帳並使用WinMerge複製更改）;我實際上有一個不同的問題：

如何測試工作副本的有效性？

當然，你總是可以簽出一個新的副本，並使用文件比較工具，但...是不是有更好的方法？是否有工具來驗證相當於svnadmin verify的工作副本？

=== UPDATE ===

我已經得到了很好的答案與技巧，以防止工作副本損壞，但我的問題是更多在尋找一種方法的線100％確保工作副本既是一致的，又與實際的存儲庫內容相關聯;在其他作品中，工作副本等效於svnadmin驗證命令。

到目前爲止，它看起來像：

Subversion不會提供這樣的工具，它有可能是SVN數據格式甚至不允許寫一個。
更新到版本是一種似乎可以找到（並修復）一些問題的技術，儘管您經常需要來回回覆舊版本，並且我認爲它只能檢測丟失的文件，如果它們已被更改在修訂範圍內。
檢出新的工作副本看起來像是唯一100％可靠的方法。

來源

2010-02-20 Álvaro González

我有類似的問題 - 重命名文件夾似乎有時會引起問題，但不是每次。 *通常*，恢復將使工作副本回到有效狀態，但未版本化的項目（重命名文件夾的「副本」側）留下。但是，我想要一個有效性檢查工具。 – Steve314 2010-02-20 11:59:12

可能的問題是工作副本的狀態是有效的，而不是你認爲應該是的。例如，對於工作副本來說，排除存儲庫中的某些文件或文件夾是有效的。只是因爲一個國家混亂而不是你的意圖，並不意味着它不能合法地產生，在這種情況下，「錯誤」是不可檢測的。列出「有趣」任何東西的「工作副本狀態」工具可能會更有用。 – Steve314 2010-02-20 12:07:34

@ Steve314：工作副本的基本內容必須與存儲庫中的基本內容相同。 Subversion是一個集中的版本控制系統，所以這是一個必需的條件，它應該是可檢測的。當然，你描述的工具也會很棒（例如，當我有來自不同存儲庫的.svn dirs時，我很樂意學習），但這是一個不同的故事。 – 2010-02-20 12:24:37

到目前爲止，我必須假定有沒有做一個可靠的方法它除非你做一個新的提交併比較兩個目錄樹。如果.snv目錄缺少數據但實際上沒有損壞，工作副本中沒有足夠的信息來檢測某些文件已經消失。

雖然WC-NG可能會改變（或不改變），但目前的格式並不穩固。

來源

2010-08-20 08:27:35

如果你右鍵單擊該文件，在SVN菜單下我相信有一個命令稱爲差異。這將打開並突出本地版本和我認爲的回購版本之間的差異。

如果您願意，也可以從命令行執行diff。

來源

2010-02-20 11:59:04 PICyourBrain

有趣的...如果我使用TortoiseSVN的「差異與URL」菜單項來比較工作副本與存儲庫樹幹我終於得到錯誤信息：路徑 D：/Project/working-copy/missing-file.php 在patchfile中不存在。 TortoiseMerge嘗試通過剝離前綴來應用修補程序，但找不到匹配的路徑。 – 2010-02-20 12:16:31

@ Steve314：你錯過了'tortoisesvn'標籤嗎？ – sbi 2010-02-20 13:05:10

@sbi - 是的，看起來我對另一個人也是錯的 - 哦，好吧。 – Steve314 2010-02-20 14:04:38

我在使用Windows上的Tortoise開始使用SVN時遇到了類似的問題。無論何時我需要複製文件夾 - 例如當創建基於另一個插件的新插件時，我已將其快速複製並粘貼到工作副本中。

我不知道的是，當你這樣做時，你沿着.svn元數據目錄複製。這會導致顛覆層出不窮 - 如果你使用圖形客戶端，新的目錄似乎已被正確檢入，客戶端在每次提交後都會顯示一塊乾淨的盤子。但是，新的目錄永遠不會在中檢查。

當您在其他地方簽出一個新的工作副本時，您會注意到這一點，然後就搞砸了，因爲這些文件從來都不受版本控制。花費我半天的時間來修復。

當您需要在工作副本中複製一個目錄時，請始終先導出它，然後將其添加回去。

來源

2010-02-20 12:22:07

這看起來像我經歷了前一段時間的一個問題：svn - file in working copy seems "lost"

逐字引述wcoenen的回答是：

SVN 1.6.1客戶端（包括 TortoiseSVN的）有一個bug，其中文件夾有時會錯誤地設置爲深度「空」。這會導致您描述的症狀。（請注意，這是可能該文件夾製作「空」通過SVN 1.6.1並一直這樣即使你已經升級到較新的svn客戶端在平均時間）。

要修復它，用「更新修改」菜單項中的TortoiseSVN和選擇深度「完全遞歸」

來源

2010-02-20 14:50:18 jeroenh

一見鍾情。在我的測試副本中，此方法已恢復丟失的文件。 – 2010-02-20 15:17:51

虛驚一場。我測試了兩個工作副本，我指出了相同的位置和版本：其中一個缺少版本化文件，「更新到修訂版」不會恢復文件（或者甚至警告有什麼問題）。 – 2010-02-22 08:41:58

如何驗證Subversion的工作副本

回答

相關問題