SVN，看細節，而林提交文件

Question

SVN的專家簡單的問題：

現在林做了第一次提交一個大項目的（不需要解釋的細節），並且它像近2 GB的文件。

承諾花了很長時間，我看到像往常一樣點點滴滴。所以我的問題是，是否有辦法顯示我的提交的詳細進度，因爲我不知道真正的進展，已上傳了多少，以及有多少未決。

謝謝

Answer 1

沒有辦法在當前的命令行客戶端上看到更多詳細信息，但您可以通過發送一封電子郵件向users@subversion.apache.org提出此建議。實際上我們有信息來打印更多的數據（傳輸速度和完成百分比可能會非常棘手，但我們至少可以提供正在傳輸哪個文件）。如果你不願意等待Subversion本身，你可以修改客戶端打印任何你想要的內容，但通知功能並不複雜。

不幸的是，David W.的回答並不準確。在服務器試圖執行提交併且數據已在服務器上時顯示時段的印象完全錯誤。這些時間段顯示爲每個文本內容的文本增量（可能是全文，在某些情況下）開始傳輸（正如在週期開始之前打印的「傳輸文件數據」所暗示的）。因此，第一個週期將在第一個文本發送時顯示，第二個週期結束後第二個週期將開始顯示，等等。所以如果你知道你提交了多少文件，你可以從這個輸出中得到一些想法。

超級技術內部細節如下。輸出在svn_client_ctx_t中設置的notify回調函數中實現（ctx是上下文的簡寫）。對於一個犯，你可以看到這是從svn_client__do_commit函數調用，如下所示爲subversion/libsvn_client/commit_util.c實施：

if (ctx->notify_func2) 
    { 
     svn_wc_notify_t *notify; 
     notify = svn_wc_create_notify(item->path, 
            svn_wc_notify_commit_postfix_txdelta, 
            iterpool); 
     notify->kind = svn_node_file; 
     notify->path_prefix = notify_path_prefix; 
     ctx->notify_func2(ctx->notify_baton2, notify, iterpool); 
    } 

本次活動是由代碼發送一個svn_wc_notify_commit_postfix_txdelta，如果你看一下代碼你」的背景下，其在發送文本增量之前發送一個路徑。

這裏，在大衛的回答上面隱藏着一小段真相。此三角洲樹已經被傳送（這意味着已經發送了副本，刪除，mkdir等）。但是，正如事件和代碼背景所暗示的那樣，文本增量在所有這些完成後都會被延遲發送。正如David所指出的那樣，這並不是特別有助於避免長時間的提交失敗，因爲他們已經過時了，但最終，即使我們優化了在Delta編輯器驅動期間發生的故障，我們仍然必須檢查試圖將事務（即在編輯驅動器完成時構建的）轉換爲任何過期情況的修訂，因爲我們在事務處理期間不鎖定存儲庫（這有助於防止Subversion在大量人們正在犯下）。我相信我們實際上已經嘗試儘快讓服務器返回錯誤，但最近我還沒有深入瞭解該代碼，因此我不打算嘗試就此做出明確的陳述。

收到所有數據後實際處理事務所花費的時間相對較小（因爲我們必須在此處理期間取回對回購的寫鎖定）。 Subversion提交速度有兩大漏洞。在DAV（http/https）的情況下，三角洲驅動器的大多數步驟發生在單獨的HTTP請求中（按照DAV和DeltaV標準的設計）。這些請求連續執行，導致往返延遲。這包括髮送文件內容。當對DAV進行大量小改動時，這大大延誤了延時。如果這是您常見的情況，您可以通過使用svnserve而不是DAV來避免此問題。在未來，我們希望通過流水線幫助緩解這一些問題。第二個問題是我們不能並行發送多個文件的文本變化。這會影響所有各種網絡協議，並且目前無法實施，因爲事務的文件系統實施不支持它。我們希望將來能夠解決這個問題，將DAV從霓虹燈切換到農奴是朝這一目標邁出的一步，因爲農奴在這方面有更多的能力。

返回通知情況。命令行客戶端的notify回調函數在subversion/svn/notify.c中通過名爲notify（）的函數實現。如果您搜索svn_wc_notify_commit_postfix_txdelta，你會發現這樣的代碼：

case svn_wc_notify_commit_postfix_txdelta: 
    if (! nb->sent_first_txdelta) 
    { 
     nb->sent_first_txdelta = TRUE; 
     if ((err = svn_cmdline_printf(pool, 
            _("Transmitting file data ")))) 
     goto print_error; 
    } 

    if ((err = svn_cmdline_printf(pool, "."))) 
    goto print_error; 
    break; 

這是你的時間得到印刷。該函數的n參數是svn_wc_notify_t，它具有提供信息的各種字段。在這種情況下，路徑，動作，類型和path_prefix都應該被設置。所以應該可以通過一些簡單的修改來容易地顯示正在傳輸的文件名。

Answer 2

簡短的回答：不，你看不到細節。在您看到這些時期的時候，您的Subversion客戶端已經將您的更改傳遞到了Subversion服務器上。現在，服務器正試圖查看它是否可以提交這些更改。此時，所有內容都在服務器上，並且服務器和客戶端之間的通信受到限制。

您的Subversion客戶端就像是1960年代期待的情景喜劇之父。沒有人會告訴他一件該死的事情，直到它結束。他只是在候診室裏上下跳動，吸着香菸，直到有人告訴他最終結果。

您的Subversion客戶端已經將更改傳遞給了Subversion服務器。當你看到這些時期時，它就是你的Subversion客戶端來回擺動，直到它從Subversion服務器聽到發生的事情（恭喜！這是一個提交！）。

現在，最大的問題是：你在做什麼2 GB的文件？如果在一大堆文件中存在一個無法提交的文件，那麼整個提交將被拒絕。所有這些都在浪費。

• 提交應該是有意義的零碎。它們越小，它們越快，最終拒絕提交的可能性就越小。在我的網站上查看一個相當大的項目，所有的源文件只有108兆字節。這是你擁有的1/20，這是一個相當大的項目。
• 不要犯建造的文物。構建的文物通常尺寸非常大，而且版本不夠好，因爲它們通常是二元的。源代碼中的微小變化將導致構建的工件有很大差異，這意味着它將佔用每個版本的幾乎那麼多空間。我的構建創建了91Mb的構建神器。如果我這樣做，它會在我的Subversion存檔中佔用另外的91MB。做這個幾十次，我已經增加了我的項目在Subversion服務器上需要的空間超過千兆字節。
   
  更糟糕的是，這個二進制文件不能用於以前的版本，所以它不能以編程方式幫助我，並且它很快就失效了。我一年前寫的源文件可能仍然與我的項目相關。但一年前建立的二進制文件對任何人都沒有用處。
• 另一種可能性：你分支並做錯了。沒有比這更糟糕的了。我用一個陳舊的鬆餅砸死了開發者，因此我被各種陪審團宣告無罪，因爲他們認爲這是完全合理的。
   
  不要建立一個目錄，將源文件從主幹複製到分支，執行svn add並提交更改。這會讓你在分支上丟失整個歷史記錄，並妨礙合併和區分，因爲就Subversion而言，分支上的文件與中繼上的文件完全不同。你失去了你的分支的全部目的，這有助於你理解它與你的樹幹有什麼不同。另外，它需要很長時間，因爲Subversion必須在您的存檔中再次添加整個項目。
   
  做一個svn cp。更好的做法是使用URL格式，而不是複製到工作目錄中。那是svn cp --parents http://server/trunk/project http://server/branch/1.2/project。這會保持你的歷史不變，Subversion幾乎可以立即創建分支。

現在，您的提交可能已完成。你被告知你的提交發生了，或者被拒絕了，並且你浪費了20到40分鐘的時間觀看那一小段時間一遍又一遍地打印出來。下一次，不要嘗試這麼大的提交。分開來。不要提交構建的工件。如果你需要一個構建的工件，你可以重建它。 （您也可以將它們存儲在其他項目中，但不在Subversion控制下）。

Answer 3

我對此做了一些調查，我做了一個很大的提交（1060個文件），最後我檢查了輸出。我發現點的數量與文件的數量完全一致（包括添加，刪除和發送文件）。

這是在Mac上完成的，但它可以在任何* nix上完成，並可能在運行cygwin或類似的窗口上完成。

我測試的方式是在「傳輸文件數據」階段開始之後，將其複製/粘貼到臨時文件中，然後執行wc -l your_file，這將使您提交全部文件。

然後計算進度複製點和echo "PASTE_DOTS_HERE" | wc -c到目前爲止得到的文件處理，然後除以總文件，乘以100，這應該給你一個粗略的進度百分比的想法。

請記住，不同大小的文件將需要更長的時間才能發送和處理，因此這些點不會全部出現。

希望能幫助別人。