SVN提交小結

在咱們用VS進行項目合做開發的過程當中，SVN的提交控制是相當重要的，因爲版本衝突形成的各類麻煩我們已經遇到的夠多了。因此，總結他們的經驗教訓，給咱們也給其餘人作個提醒。下面的第一部分是須要在正式開發以前須要作的，第二部分是開發的過程當中須要注意的。

1、排除沒必要要的提交

  1.將編譯性的文件排除在提交以外

     因爲編譯性的文件（包括obj文件夾和bin文件夾）並非源文件，它徹底能夠經過存儲的源文件生成，一次提交的話會形成兩方面的影響：1. 浪費服務器存儲空間 2. 因爲每一個團隊成員編譯的結果可能並不同，大大增長了版本衝突的概率。

  1.1 obj文件夾

        obj目錄是用來保存每一個模塊的編譯結果，在.NET中，編譯是分模塊進行的，編譯整個完成後會合併爲一個.DLL或.EXE保存到bin目錄下。由於每 次編譯時默認都是採用增量編譯，即只從新編譯改變了的模塊，obj保存每一個模塊的編譯結果，用來加快編譯速度。是否採用增量編譯，能夠經過：項目屬性— >配置屬性—>高級—>增量編譯來設置。

   1.2 bin文件夾

        bin目錄用來保存項目生成後程序集，後置代碼類和其餘非頁面類編譯後的DLL。它有Debug和Release兩個版本，分別對應的文件夾爲 bin/Debug和bin/Release，這個文件夾是默認的輸出路徑，咱們能夠經過：項目屬性—>配置屬性—>輸出路徑來修改。

  2. 將屬於每一個用戶的文件排除在提交以外

   2.1 *.csproj.user

        .csproj.user文件是一個xml文件，用於存儲當前項目的用戶配置，可使用記事本打開。例如：打開ASP.NET項目 的.csproj.user文件後會看到一 項：<StartAction>CurrentPage</StartAction>，它表示當按F5開始調試，或者 Ctrl+F5開始運行時，首先打開的是VS的當前頁。

  2.2 *.suo

        *.suo解決方案用戶選項，記錄全部將與解決方案創建關聯的選項，以便在每次打開時，它都包含用戶所作的自定義設置，好比VS佈局以及項目最後編譯的而 又沒有關掉的文件用於下次打開時用。刪除以後，團隊成員從服務器下載下來以後再次打開解決方案就會從新生成。

  3. 排除方法

     在服務器上直接將以上的文件或者文件夾直接排除掉便可，不要幻想各個團隊成員會本身在客戶端排除掉：

右擊解決方案文件夾→TorToiseSVN→Settings→General，以下圖：

        在「Subversion下的」「Globalignore pattern 」中添加要排除在提交以外的文件類型（以空格分隔）「bin obj *.suo*.user *.csproj.user」便可。

        也可右擊目標→TorToiseSVN→Unversion and add toignore list→文件類型，逐個排除。

        排除後之後再提交整個解決方案，被排除的文件類型都不會被提交：

 

 

2、提交的幾個原則

 1.先更新，再生成解決方案，最後提交。

  1.1 先Update整個解決方案

        團隊成員可能會修改解決方案中的多個文件，因此更新的時候咱們沒有必要（也不建議這麼作）去單個項目或者文件去更新，不然可能更新下來的代碼因爲只是部分致使生成的時候出現錯誤。

   1.2 而後保證在提交以前生成的解決方案沒有錯誤

        這個是提交以前最爲重要的一步，一旦某個成員提交上了這種類型的代碼，那麼團隊中的其餘人都將沒法進行調試。

  1.3 最後再提交，並且只Commit本身修改的類

       只提交本身修改的類或者其餘文件，避免由於誤操道別人的類致使解決方案中的出錯。其實能夠經過SVN的權限控制各個成員負責的部分，能夠精確到單個類（但這種方法也有很多侷限性），這樣就能夠大大減小因爲誤操做引發的沒必要要的麻煩。

       對於新添加的類、文件或者文件夾等咱們應該將他們所在的層進行提交（固然也能夠對整個解決方案進行提交，但爲了減小出錯的概率採用此方法），提交的時候勾選上*.csproj文件（默認是勾選的）和本身修改過的：

     這樣就能夠解決下載的解決方案中新建的這個文件夾未被包含在項目中的問題。

     而對於新添加的項目，則應該提交整個解決方案，方法跟上面相似。

  2.「微提交」

      每實現一個小功能或者幾段代碼，生成沒有錯誤以後就直接提交，也叫「保存提交」。這樣能夠經過SVN的版本控制，最大程度的減小由於後來的錯誤致使解決方案大範圍修改狀況的發生。

 3.未經組長贊成，不得擅自使用「get lock」功能

     就是對文件或者文件夾進行「鎖定」的功能。只有對於特別重要的，屬於只有本身可以修改的而且通過組長統一的纔可以使用。不然其餘人沒法提交該文件或者文件夾。

 4.對SVN提交更新的信息採用明晰的標註(相似在代碼裏寫的註釋)

     有了這個信息以後咱們若是某個版本出現了錯誤就能夠清晰的看到是由於誰修改了哪些部分致使的，很方便調試還原。如：咱們規定的格式是：姓名—修改內容

 5.不要提交本身不明白的代碼

     代碼在提交入SVN以後，你的代碼將被項目成員所分享。若是提交了你不明白的代碼，你看不懂，別人也看不懂，若是在之後出現了問題將會成爲項目質量的隱患。所以在引入任何第三方代碼以前，確保你對這個代碼有一個很清晰的瞭解。    

     以上幾點作到以後，之後出現的問題只要是關於版本提交的基本上就能解決了。在實踐的過程當中可能還會有以上問題的出現，但只要咱們可以清楚這些問題的來源，就可以比較快速、正確的處理掉。固然，仍是須要你們去養成一個良好的提交習慣才能避免給你們帶來麻煩。