使用svn的合理姿勢
何爲合理的姿勢
我將svn的使用指南起這樣一個名字，是因爲很多公司使用svn作爲版本管理工具（雖然git更好用），可以說我們每天都在使用svn，但我們使用的真的合理嗎。要回答這個問題，只需要問自己幾個問題：
- 我們還在通過foo.c.bak的方式備份文件嗎？
- 我們還在爲“合版本”花費大量時間，而且叫苦連天嗎？
- 我們還會有“xxx修改是xx個月之前的事情了，不記得爲啥要改了”這樣的說法嗎？
- 我們還在通過即時聊天軟件互相發送修改的文件嗎？
如果答案是肯定的，那麼我們就沒有以合理的姿勢使用svn，沒有領會svn的精髓，姿勢不正確，幹活效率自然不高。爲瑣事分心，心情自然也不好。
所以我寫這篇文章，旨在討論一種使用svn的合理姿勢，讓svn的使用成爲我們軟件開發的一部分，成爲我們血液裏的東西，成爲我們靈魂的一部分，而不是作爲僅僅作爲一個網盤。
分支的使用精髓
一般來說，一個svn的工程至少都會包括trunk和branch兩個路徑，一個用來存放主幹版本，一個用來存放分支。
關於這兩個目錄的主流使用方式有兩種：
- 所有的開發都在trunk目錄下進行，在需要開發新功能或有其他需求時進行branch，而branch出的新路徑又類似於一個新的分支，大家關於新功能的開發都在這個新的分支下進行。
- trunk目錄只接受相對穩定的提交。每個人的工作都在自己的分支下進行，當一個功能相對穩定時再向trunk目錄提交。
我個人來說是更傾向於第二種方式的，因爲更有利於團隊合作。第一種方式對於一個人的開發可能問題不大，兩個人的開發如果軟件架構設計的很好的話，應該也沒什麼問題，但如果參與開發的人多了，同時軟件架構相對來說耦合性又較大的情況下，就要亂套了。
試想你正在修正代碼庫中一個令人頭疼的bug，而你的同事正在開發一個新功能，而你們倆又都在同一個trunk目錄下工作。那麼你修復bug的過程中commit的代碼可能會使代碼庫不能正常工作了，那麼你的同事在update新代碼後在你這不能正常工作的調試版本上開發新功能，發現出現各種莫名其妙的錯誤，最後發現原來是你上傳了不能使用的代碼，你倆就等着吵架吧。:)
那麼你可能會說，我修正bug的過程中可以先不commit呀，等我測試成功了再commit，這樣就不會影響同事新功能的開發了。恩，這麼說也沒錯，但你不實時commit，而是等三個月後bug測試成功了再commit，那麼你告訴我，你的svn跟網盤有什麼區別。而且三個月後代碼可能已經被很對人改過了，這時候你想把你的代碼在commit上去，相信我，解決三個月來產生的衝突絕對讓你產生想撞牆的衝動。
所以咯，爲了我們的能夠保持愉快的心情，我贊成第二種分支使用方式。大家都不可以在主幹版本上直接commit，都必須在自己的branch上進行開發與調試，在自己的branch上積極commit，記錄下log，可以在不影響他人的情況下隨心所欲的記錄下自己思想的軌跡，幾年之後想要看自己當初看法的思路，看看當年的log,整個心路歷程就都有了，想想是不是還有點小激動呢~(≧▽≦)/~
當你在自己的分支調試穩定之後，就可以向主幹merge了。其實這裏還有個問題不知你有沒有想過，就是解決開發過程中別人上傳的代碼與你的開發產生的衝突還是需要解決，如果積累三個月，代碼可能已面目全非，想要解決衝突可能仍然讓你頭疼到想撞牆。那怎麼解決這個問題呢，答案是多跟trunk保持來往。
親戚朋友時間長不走動就生疏了，branch和trunk時間長不來往互相就不認識了。所以我們開發過程中應該經常跟trunk保持聯繫。
怎麼保持聯繫呢，不能總是向trunk合併，但是可以經常從trunk向自己的branch合併呀。每天開始一天的工作之前，我們都可以從trunk版本向branch進行合併，解決衝突，畢竟少量的衝突解決起來不會很難。
分支的使用方法
前面從宏觀角度探討了分支的使用方式，下面就要着眼於具體，說說如何操作了。這方面筆者目前也處於一瓶子不滿半瓶子咣噹的階段，有什麼錯誤大家及時糾正。
1. checkout出主幹目錄
第一步沒什麼可說的，大家非常熟悉了，在一個空目錄下右鍵，點擊checkout，在”URL of resposity”中輸入主幹版本的svn路徑，點擊OK即可。
2. 創建自己的分支
這裏我們選在在svn服務器上創建我們自己的分支，在一個目錄下右鍵，Tortoise->Branch/tag，如下圖：
然後在to path中填入自己的分支的路徑，填寫log，選擇HEAD revision in the respository，點擊OK。
這樣，我們就在svn服務器上創建了一個自己的分支。
3. 將自己的分支checkout出來
現在自己的分支還在服務器上，我們可以像檢出主幹版本一樣在自己的工作路徑下檢出自己的分支。
4. 將自己的branch合併到trunk
合併分支這個事兒記住一點，向哪裏合併，就在哪裏操作。
既然是合併到trunk，就在trunk的路徑下操作。在本機trunk目錄下右鍵，Tortoise->Merge，如下圖：
然後選擇Reintegrate a branch，點擊Next
然後填入自己的分支的URL，點擊Next,可以先Test merge一下，最後點擊Merge開始合併。
合併後記得在trunk路徑下commit
5. 將trunk合併到自己的branch
還記得上文說過跟trunk保持來往嗎，所以我們更多的操作應該是從trunk向自己的branch進行合併，解決衝突。
操作是在自己的branch目錄下進行的，與向trunk合併的方式類似，右鍵，Tortoise->Merge，然後選擇Merge a range of revisions，點擊Next，輸入trunk的路徑，進行合併操作。
這裏再次強調，經常性的從trunk向自己的branch合併，能夠使自己的代碼保持新鮮。另外不要吝嗇於commit操作，反正也不會影響到別人，多多commit，多多記錄log有百利而無一害。
