在很久很久以前，我們是怎麼進行版本控制的呢，當我們工作到某個階段後，就把此時的專案存為乙個資料夾(a)，然後再從這兒複製出乙份(b)接著修改，而儲存的那個資料夾(a)就是我們打的版本號，當我們把b改動到某個階段後再打乙個版本，然後從這個版本裡衍生出乙個c，一直衍生下去……。如果我們在某個版本改壞了的話，我們再從上個版本複製出乙份接著修改。
本人當時在學校的時候對版本控制了解的不深，就是用的這種方式進行版本控制的，這種手動進行版本控制的乙個壞處就是：我們不知道每兩個版本的差異在哪兒，都修改了哪些檔案，只能說是這個版本比上個版本多了幾個功能，可是檔案的差異在哪兒，就不好對比了。不過後來在工作中遇到了svn，這種情況就改善了很多。
當時小蚊使用svn時，每次我要對某個專案的**進行改動時，都先從伺服器上down下乙份**來，然後開始修改。因為本地的**已經很老了，如果其他人也提交了**的話，我再用我本地的老**進行提交，就可能出現**覆蓋或檔案衝突的情況。剛開始使用時都沒有寫改動資訊，後來發現同事會在專案里弄乙個changelog.txt來儲存每次的修改，然後我也跟著學。可是後來發現原來svn本身就有記錄改動日誌的功能，從這兒之後才算是開始步入正軌，真正地接觸到了版本控制系統。
當我開始接觸github時，慢慢地使用上了git這個版本控制系統，可是因為是專案只有自己在改，也沒有學習到很多。
後來換了新工作之後，新公司使用的是mercurial作為版本控制系統，在工作中學習到了很多分布式版本控制系統的知識。
hg和git有著無數的相似之處，都是分布式版本控制，都是有分支。git我只是在提交自己的專案時使用，很多的東西還沒用到，不過工作中使用的是hg，每天都在多人合作**，常會遇到合併分支時出現檔案衝突、推**時出現多個相同的分支。
什麼是分支，分支是幹什麼用的？
像以前傳統時的那種版本控制系統，整個專案都是集中乙個伺服器上，任何的修改都是要先從整個伺服器上拉取**，修改完成後再上傳上去，若在修改的期間，其他人也提交了**，最後自己提交的時候可能會覆蓋掉上乙個人的改動；現在分布式版本控制系統的優勢就是，乙個分支就是乙個**庫，你在該分支上進行的任何操作都不會影響到其他分支，如果把整個分支整壞了，或者想放棄這個分支，那麼直接切回到default分支重新新建即可，在那個分支上所有的改動都被保留在了那個分支上。
hg clone rep 從rep的位址拉取**
hg status 檢視當前倉庫中的檔案改動狀態：
m: 內容已改動；
！（感嘆號）：版本庫還在跟蹤該檔案，可是本地倉庫已經丟失該檔案
r：該檔案從版本庫中刪除；
？（問號）：本地倉庫中新新增的檔案，版本庫里還沒有該檔案，需要使用hg add 檔名 新增到版本庫中
a：該檔案是新新增的
hg remove 檔名 版本系統不再跟蹤該檔案
hg revert 檔名 恢復該檔案
狀態是！(感嘆號)的，需要進行二選一了，是該檔案真需要刪除了，還是被誤刪了；若真的需要刪除，則使用hg remove 檔名，若被誤刪了則使用hg revert恢復該檔案
hg add . 將所有沒有在版本控制系統的檔案新增到控制系統中，
hg add 檔名 是將某個檔案新增到控制系統中 hg log 檢視提交的歷史資訊
hg commit 將本地的改動進行提交
hg push 將改動推到遠端的分支上
hg merge 分支名 將其他分支的**合併過來
hg diff 檢視改動，hg diff 檔名 檢視該檔案的改動
當前分支拉取當前分支不用merge，直接hg pull -u
取消當前分支的修改回到最初狀態時，hg update -c
切換到其他分支且不保留當前分支的修改時，hg update default -c
切換到其他分支且保留當前分支的修改時，hg update default
建立分支時要在default分支上進行建立，這樣保證所有的分支沒有瓜葛；若在其他的分支上直接建立分支時，則把上乙個分支的修改保留了下來，不容易進行拆分；視情況而定
若第一次提交分支時，則使用hg push -b 當前分支名 –new-branch，若已經是第二次以上的提交了則使用hg push -b 當前分支名即可，當然，每次提交時都帶著—new-branch也沒錯
多人合作時需要拉取別人的分支的**，不要擔心，別人的分支和default分支沒有任何區別
7.1 在default分支上拉取遠端的**並更新本地**:
hg pull -u(hg pull, hg update)
7.2 在default分支上新建自己的分支:
hg branch 自己的分支名
7.3 合併他人的分支:
hg merge 他人的分支名
7.4 將合併的先提交一下，不然一會兒自己的改動和剛拉取的他人的**混到一起了:
hg commit -m 『merge from xiaoming』
7.5 進行自己的改動，該修改的修改，該新增的新增，該刪除的刪除
7.6 提交自己的修改:
hg commit -m 『改動原因或目的』
7.7 再拉取下遠端的**，在改動的過程中說不定已經有人更新default分支了，不合併的話，會把別人的提交弄丟:
hg pull -u
hg merge default
hg commit -m 『merge from default』(若merge default時需要提交)
7.8 將自己的**推送到遠端**庫:
hg push -b 自己的分支名 –new-branch
配置 .hg目錄
8.1 grc : hg的遠端**庫位址 ，若遠端位址改動了 ，不用從零開始在新的位址拉取，只需要在這個檔案中可以修改位址即可
[paths]default = ssh://
8.2 branch : 當前的分支 ,這個檔案裡儲存著當前的分支名
8.3 last-message.txt : 最後一次提交的資訊，hg commit -m 『message』
9. 合併分支時出現衝突或出現推**時出現多個相同的分支(多頭)，怎麼辦？
當我出現這個的狀況時通常是使用sourcetree的這個視覺化工具來解決的，sourcetree上安裝kdiff3的外掛程式，當合併時出現了衝突，能夠很明顯的看到檔案的哪部分出現了衝突，然後應該選擇哪個作為需要合併的部分 當出現多個相同的分支時，把其他相同的分支直接merge到乙個分支上，然後再推**。
當然，這裡也只是個人經歷的總結而已，依然還有很多的東西沒有總結到位。
fastjson的使用心得
這個的使用很簡單，但今天下午犯二搞了很久，整理下 以免下次犯同樣的錯 1 錯誤 對json的格式想當然了 描述 json 字串拼錯了，造成怎麼解析都不對 下面是錯誤的示範 name jack psd piao city name name 就是在陣列中定義的時候錯了，乙個很2 的錯誤，今天搞的頭大 ...
ShareSDK的使用心得
最近要寫個微博關注的功能，看了很多資料，好多人說推薦友盟，說那個很好用，後來對比了還是選了sharesdk，我只是需要乙個關注功能。redirecturi 然後就是編寫關注的 在授權頁面中新增關注官方微博 authoptions setfollowaccounts nsdictionary dict...
C ThreadPoold的使用心得
在c 多執行緒程式設計中經常要使用執行緒，但是因為得執行緒的建立和撤銷是非常消耗資源的代價很大，因此我們使用執行緒池來解決這個問題，執行緒池就是在一開始向系統申請一定數量的執行緒，並維護它，有任務來時，如果有空閒執行緒的話就分配乙個執行緒給它執行，如果沒有空閒的執行緒就得等待。當執行緒執行完任務後，...