版本合併
svn merge from_url@from_ver to_url@to_ver .
意思是把from_url的from_ver版本到to_url的to_ver版本變化施加到當前工作區
比如你打branch的時候版本是a，開發完了版本是b，那麼這個命令就是把a到b做乙個diff，然後patch到當前目錄
檔案衝突
如果是不同檔案，肯定不會有衝突
如果相同檔案，在不同的行數，也不會有衝突
只有在相同檔案，在相同行數，會導致衝突
這個時候merge會提示有問題，一般需要手動修復，輸入e（edit），進行收到修復，合併**，修復完了之後儲存輸入r（resolved）告訴svn你已經修復完了
多人合作開發
開發都在分值上面進行
上線的包也是在分支打包
等確認上線沒有問題了，在合併到trunk
這樣做的目錄是保證trunk乾淨
常見問題：
在版本x1，a同學和b同學都fork了乙個分支出來進行開發
a開發完了版本記做x2，然後a進行預發，發布，合併trunk
然後b開發完了，他需要把trunk的最近更改合併到分支上面來就用merge trunk@x1->trunk@x2 .合併過來
b進行測試，上線，然後再合併trunk merge trunk@x3 branch@x3 trunk，相當於用這個分支直接替換掉trunk，因為這個分值有之前的trunk的功能，也有b開發的功能，是包含a和b的功能部分的，因此可以進行替換。
git多人合作開發指令
往往乙個專案是多人開發的，而分支正是用於滿足我們的要求，乙個分支可以交給乙個人開發系統的乙個功能，而系統的總功能在master分支上，這樣不同的分支不會相互影響，當ta開發完以後，通過協調溝通確保 無誤後講分支進行合併到master，即可把完成的某個功能加入到系統的總功能中。或許這是超級無敵精簡的g...
使用git進行團隊合作開發
1.git 和 svn 的差異 git和svn 最大的差異在於git是分布式的管理方式而svn是集中式的管理方式。如果不習慣用 管理工具，可能比較難理解分布式管理和集中式管理的概念。下面介紹兩種工具的工作流程 團隊開發 通過閱讀下面的工作流程，你將會很好的理解以上兩個概念。集中式管理的工作流程如下圖...
合作開發總結
合作開發從開始的興奮到後來的迷茫 到雲層漸漸的散去,到萬里晴空,到系統最後的竣工 切切實實的感受到了軟體工程這一的過程些許的韻味.人員分配方式.因為小組人數是三人 所以此次合作開發是人員的分配是面向包的 而不 是面向層的 是乙個人負責幾層.此次開發依照原則.做了這麼多遍的機房收費系統了,不能再是開始...