1、程序需定期編譯通過后上傳SVN，每天可上傳多次，根據個人程序開發進度決定，但每天晚下班前必須將當天的程序編譯調試通過並上傳SVN。每天早上上班首先需要更新SVN最新版本。
上傳的工作流程應該是，更新——編譯運行——上傳。這個工作流程那一步也不能缺少。更新是在把 別人提交的代碼下載下來，看看和自己所寫的代碼有沒有什么沖突，可能自己需要用到的一個函數已經被別人所修改。導致自己本來運行完美的系統出現了錯誤。如 果沒有編譯運行就上傳了。別人下載下來的代碼就是錯的了。這樣通過幾個版本的迭代。出現的錯誤就很難被發現與糾正。這就又產生了一個原則：任何時候不能把錯誤的代碼往服務器上傳。對於多次上傳，主要目的是把損失降低到最低，這樣一旦出現了錯誤恢復上一個版本的損失才會最少。但每天晚下班前必須將當天的程序編譯調試通過並上傳SVN。對於這一點有兩個重要意義：1.每天老板都知道你今天干了多少活。2.把今天的工作告一段落，沒有壓力的開始明天的工作。明天其他人的任何更改都不會影響你今天的工作。
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客戶端添加到忽略列表中。
1、解決方案的suo文件
2、工程的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文件等）時，才適當的采用鎖定操作。