開發背景：
簡述現有流程：代碼的合並、提交是以任務為最小單元的。例如A和B兩個同學開發不同的任務，那就是兩個任務號。合並的時候可能會先合並A的代碼，在合並B的代碼。
需求：SVN合並程序開發——一款能夠滿足測試人員合並代碼的工具，通過輸入任務號或版本號及選擇合並分支，將對應的任務及版本合並到選擇的分支上。
要求：避免SVN沖突。
工作要點：設計一個即能減少沖突，又能提交次數最少的流程。使用SVNKIT完成設計工具，最好是圖形界面客戶端。
梳理思路：
個人覺得在合並過程中沖突是無法完全避免的，A和B同時改一段代碼，就有可能造成沖突。那么，現在我們要做的就是如何合並能夠減少沖突。比如針對代碼有交叉的任務，按照提交順序合並代碼？暫且按照這個方向做~
開發思路：
1.首先要對svn本身有一個良好的認識，基礎。
2.學習svnkit的使用，核心。
3.圖形界面客戶端調用java代碼，擴展。
工作：
當天晚上就對着官網開擼，英文水平雖然不是很高，但是配合各種翻譯軟件加自己的聰明才智勉強看懂。那么問題來了，官方除了大的框架介紹、java doc文檔，沒有可用的示例代碼（示例代碼的連接是wiki.svnkit.com，拋出服務器500異常）。當時腦子里有三個想法：1.想着要不要聯系一下官方，2.搜以前大神些的博客，3.對着java doc自己看源碼。可能是由於svnkit並不是特別的火，大家都喜歡用現成的svn工具，或者用git等等，所以網上使用svnkit做svn二次開發的例子少之又少，而且均是舊版本的例子。最終照着網上大神寫好的文檔和一些實例代碼，結合javadoc+源碼完成了一部分的功能（import、checkout、commit、update等），但是感覺個人從對svnkit的理解上並沒有太大的深入。萬般無奈之下找了下svnkit的郵箱，給他們發了一封郵件，附上問題鏈接和截圖。然后繼續對着javadoc進行功能開發。上午都沒有收到回復，有點遺憾。不過后來一想，老外和咱們有時差，應該還在睡覺。終於到快下班的時候，不小心點到官網wiki上的鏈接，竟然進去了。特別高興的登上郵箱，果然收到了對方的郵件（不得不佩服，人家解決問題的效率還是比較高的）
問題解決了好開心，盡快搞定svnkit后解決圖形化界面的問題。還要和測試同學溝通合並的方案~
總結：
1.遇到自己解決不了的問題，除了自己思考和動手解決，也要在第一時間反饋給可能對解決問題有幫助的人。
2.希望自己能養成看源碼的習慣，對着javadoc看源代碼理解起來確實不錯。
好了，結束我人生的第一批博客吧，晚上照着wiki繼續搞一下，加油~