VS中使用svn注意事項

一、程序需按期編譯經過後上傳SVN，天天可上傳屢次，根據我的程序開發進度決定，但天天晚下班前必須將當天的程序編譯調試經過並上傳SVN。天天早上上班首先須要更新SVN最新版本。 

上傳的工做流程應該是，更新——編譯運行——上傳。這個工做流程那一步也不能缺乏。更新是在把 別人提交的代碼下載下來，看看和本身所寫的代碼有沒有什麼衝突，可能本身須要用到的一個函數已經被別人所修改。致使本身原本運行完美的系統出現了錯誤。如 果沒有編譯運行就上傳了。別人下載下來的代碼就是錯的了。這樣經過幾個版本的迭代。出現的錯誤就很難被發現與糾正。這就又產生了一個原則：任什麼時候候不能把錯誤的代碼往服務器上傳。對於屢次上傳，主要目的是把損失下降到最低，這樣一旦出現了錯誤恢復上一個版本的損失纔會最少。但天天晚下班前必須將當天的程序編譯調試經過並上傳SVN。對於這一點有兩個重要意義：1.天天老闆都知道你今天干了多少活。2.把今天的工做告一段落，沒有壓力的開始明天的工做。明天其餘人的任何更改都不會影響你今天的工做。

 

二、在程序中添加頁面、刪除頁面及修改頁面命名時，須要先更新所有程序特別是解決方案文件，而後再作添加或者刪除頁面以及修改頁面名稱，作完這類操做後需馬上上傳SVN，以避免形成解決方案衝突 

先說什麼是解決方案衝突：

csproj文件你們應該不會陌生，那就是C#項目文件的擴展名，它是「CSharp Project」的縮寫。那麼它到底是給誰用的呢？那是給開發工具用的，例如咱們在熟悉不過的VisualStudio，以及你們能夠沒有接觸過，可是應 該都據說過的MSBuild.exe。VisualStudio會根據csproj裏的XML定義來管理項目文件以及相關其餘一些種類很是豐富的數據及操 做，MSBuild也會根據csproj文件來得知編譯這個項目須要有哪些依賴，默認輸出路徑，Pre-Build和Post-Build須要哪些操做等 等。VisualStudio和MSBuild都是開發工具，這就是csproj存在的惟一意義：爲「開發環境」提供信息。而到了運行環境中，根本不會有 人（操做系統？）關心所謂的csproj文件——也就是「程序是哪裏來的」。

瞭解了csproj文件也就能理解什麼是解決方案衝突了。你在程序中添加頁面、刪除頁面及修改頁面命名時都是須要修改這個管「程序是哪裏來的」的這個文件的。這樣若是你下載下來添加了頁面，而後提交了。他也下載下來而後也提交，是必定會出現版本衝突的。（固然以上原則不僅是添加頁面時，添加類也是同樣的。）這個時候技巧2，就顯得尤其重要了。 

 

3.如下文件不容許提交到SVN上，應在本地經過SVN客戶端添加到忽略列表中。

一、解決方案的suo文件

二、工程的bin文件夾和obj文 

這些又是什麼文件呢? 

suo文件 

suo(solution useroptions)是一種文件的格式。*.suo解決方案用戶選項，記錄全部將與解決方案創建關聯的選項，以便在每次打開時，它都包含用戶所作的自定義設置。好比VS佈局以及項目最後編譯的而又沒有關掉的文件用於下次打開時用。

其中，VS佈局包括：監視器1234的變量列表、斷點標記及開關狀態、輸出窗口錯誤窗口等的分佈及其懸浮狀態，還有項目卸載狀態標記。

.suo文件偶爾會被破壞，從而在構建和編輯應用程序時出現意想不到的結果。若是VisualStudio對於每一個解決方案不穩定，就應刪除.suo文件。下次打開解決方案時，Visual Studio會重建它。

 

bin和obj文件夾 

bin是放最終代碼的目錄

obj就放中間代碼的目錄

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

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

能夠看出這些文件都是根據本地的信息產生的配置文件，每一個人和每一個人的均可能是不同的。因此上傳的時候應該屏蔽。等到本身更新了最新版本。從新編譯，就會自動的產生可使用的本身的配置文件了。

 

這些技巧更應該說是咱們要培養的工做習慣，只用有了這些工做習慣咱們的合做開發纔會更加的愉快，更加的和諧。

---

先更新，再提交 
SVN更新的原則是要隨時更新，隨時提交。當完成了一個小功能，可以經過編譯而且本身測試以後，謹慎地提交。 
如 果在修改的期間別人也更改了svn的對應文件，那麼commit就可能會失敗。若是別人和自 己更改的是同一個文件，那麼update時會自動進行合併，若是修改的是同一行，那麼合併時會產生衝突，這種狀況就須要同以前的開發人員聯繫，兩我的一塊兒 協商解決衝突，解決衝突以後，須要兩人一塊兒測試保證解決衝突以後，程序不會影響其餘功能。 
在更新時注意所更新文件的列表，若是提交過程當中產生了更新，則也是須要從新編譯而且完成本身的一些必要測試，再進行提交。這樣既能瞭解別人修改了哪些文件，同時也能避免SVN合併錯誤致使代碼有錯。

 

多提交 
每次提交的間歇儘量地短，以幾個小時的開發工做爲宜。例如在更改UI界面的時候，能夠每完成一個UI界面的修改或者設計，就提交 一次。在開發功能模塊的時候，能夠每完成一個小細節功能的測試，就提交一次，在修改bug的時候，每修改掉一個bug而且確認修改了這個bug，也就提交 一次。咱們提倡多提交，也就能多爲代碼添加上保險。

不要提交不能經過編譯的代碼 
代碼在提交以前，首先要確認本身可以在本地編譯。若是在代碼中使用了第三方類庫，要考慮到項目組成員中有些成員可能沒有安裝相應的第三方類庫。項目經理在準備項目工做區域的時候，須要考慮到這樣的狀況，確保開發小組成員在簽出代碼以後可以在統一的環境中進行編譯。

每次提交必須書寫明晰的標註 
在一個項目組中使用SVN，若是提交空的標註或者不確切的標註將會讓項目 組中其餘的成員感到很無奈，項目經理沒法很清晰的掌握工做進度，沒法清晰的把握這次提交的概要信息。在發現錯誤後也沒法準確的定位引發錯誤的文件。因此， 在提交工做時，要填寫明晰的標註，可以概要的描述所提交文件的信息，讓項目組其餘成員在看到標註後不用詳細看代碼就能瞭解你所作的修改。

提交時注意不要提交本地自動生成的文件 
例如eclipse中的.classpath文 件，Windows生成的縮略圖Thumbs.db，項目編譯生成的臨時文件.obj, .class等等。若是項目中沒有進行這方面的配置來強行禁止提交這樣的文件，請自覺不要提交這樣的文件。提交了這樣的文件後，別人在更新後就可能與本地 的環境衝突從而影響你們的工做。

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

慎用鎖定功能 在項目中要慎用鎖定的功能，在你鎖定了一個文件以後別人就沒法繼續修改提交該文件，雖然能夠減小衝突的發生率，可是可能會影響項目組中其餘人員的工做。平時只有在編輯那些沒法合併的文件（例如圖片文件，flash文件等）時，才適當的採用鎖定操做。