1、版本
確定要做定製需求開發的時候，是3月15日，確定下來第一批需求的交付時間，是4月10日。當時主版本還在tr5階段，而且版本還很不穩定。
在這種情況下，在主版本上做定製需求的開發是不合適的。因為：
首先，主版本一直在修改問題合入**，而定製需求開發也需要合入大量**，這必定會有衝突。可能造成主版本無法按時轉測試，也可能造成定製需求的延誤。
其次，以當時的版本狀況，主版本不可能在4月10日發到一線使用，所以即使在主版本開發，也無法把主版本發出去。
因此唯一的選擇，就是在主版本上拉出分支。主版本繼續修改問題，在分支版本上開發定製需求，在4月10日，將分支版本發到一線。
最終是從b080拉出分支spc200t和spc300t，分別進行捷克和上海2個局點定製需求的開發。
----------------------------------------------->主版本（b080）
----------------------------------------------->spc200t（基於b080）
----------------------------------------------->spc300t（基於b080）
接下來在4月10日，第一批定製需求發到一線，需要進行第二批需求的開發，計畫在5月10日以公升級包的方式發布到一線
同時，這時候還有一件事情，對最終的措施有重要影響：即每週需要針對一線發現的問題出補丁。
為什麼這件事情很有影響呢，因為如果說當時的策略是，一線發現的問題，在5月10日的公升級包裡一起解決的話，那麼我們就可以直接在spc200t和spc300t上修改，同時進行定製需求的開發，然後在5月10日一起提供公升級包
或者甚至當時的策略是，一線發現的問題，在用主版本做版本替換的時候解決就可以的話，那麼連spc200t和spc300t都不需要改了，這2個分支只需要做定製需求開發，一線發現的問題在主幹上修改就可以了
既然確定是每週要出補丁到一線，那就沒法直接在spc200t和spc300t上進行問題修改了，否則的話補丁內容就會與第2批定製需求的內容相互衝突。
所以這時候，就在spc200t和spc300t上又拉了乙個短暫的分支。在spc200t和spc300t上繼續做第2批定製需求的開發，在分支上出補丁到一線
----------------------------------------------->主版本（b090）
----------------------------------------------->spc200tb011
------------------------------->spc200t分支（基於spc200tb011）
----------------------------------------------->spc300tb011
------------------------------->spc300t分支（基於spc300tb011）
然後在5月10日發布第2批定製需求的時候，把spc200t分支和spc300t分支上修改的問題，都合入了spc200t和spc300t，連同第2批定製需求一起發到一線。spc200t分支和spc300t分支銷毀
這時候版本線又恢復成這樣：
----------------------------------------------->主版本（b110）
----------------------------------------------->spc200tb021
----------------------------------------------->spc300tb021
這個時候主版本基本穩定，計畫在6月上旬用主版本替換一線的分支版本，所以將spc200t和spc300t上的前2批定製需求**合到了主幹裡。
但是在版本替換結束之前，還是需要出補丁支援一線，所以spc200t和spc300t還是需要保留
同時，要開始開發第3批（最後一批）定製需求了，出於同樣的原因（不影響主幹測試、不影響分支出補丁），又基於b110拉出乙個分支spc500t專門做第3批定製需求的開發，所以版本線變成下面這樣：
----------------------------------------------->主版本（b110）
----------------------------------------------->spc200tb021
----------------------------------------------->spc300tb021
----------------------------------------------->spc500t
這就形成了4個版本同時存在的情況：
主版本已經合入了前2批定製需求的**，正在繼續測試過tr5
spc200t和spc300t繼續保留，為了出補丁支援一線，這條線上修改的問題，要同步合入到主幹版本中
spc500t專門進行第3批定製需求的開發
然後在6月上旬，用主版本替換掉一線的分支版本，到此時spc200t和spc300t就廢棄了。接下來把spc500t上的定製需求合到主版本上，基於主版本出公升級包。然後將公升級包發布到一線，spc500t也廢棄了。以後一線就只有乙個版本，所有問題都只在主線上修改，版本線變成下面這樣：
----------------------------------------------->主版本（tr5）
以上就是此次定製需求開發、收編、主版本過點這些活動背後的版本走向
2、分支
確定分支策略，乙個很關鍵的因素是發布的計畫。或者說，發布計畫就是版本計畫
乙個分支等於一套**，分支越多，維護成本就越高。所以分支的數量不能太多，存在的週期也不宜太長。拉出了分支以後要盡快地收編合入主幹版本，減少維護的工作量
分支上的修改一定同步到主幹上（可能是第一時間同步，也可能是晚一點同步），但是反之，主幹上的修改，則不一定要同步到分支上。可以看作乙個樹形，比如下圖：
----------------------------------------------->主版本（b090）
----------------------------------------------->spc200tb011
------------------------------->spc200t分支（基於spc200tb011）
----------------------------------------------->spc300tb011
------------------------------->spc300t分支（基於spc300tb011）
比如在spc200t分支上發現乙個問題，那除了要在spc200t分支上修改（為了第一時間出補丁）之外，還需要在spc200tb011和b090上同步修改，否則稍後替換的時候，修改過的問題就會被覆蓋掉
但是如果是在b090上發現的問題，如無特殊情況，則不需要向下同步到spc200tb011和spc200t分支上
關於stringstream的一些總結
c 標準庫中的提供了比ansi c的更高階的一些功能，即單純性 型別安全和可擴充套件性。可以使用這些庫來實現安全和自動的型別轉換。如果你已習慣了風格的轉換，也許你首先會問 為什麼要花額外的精力來學習基於的型別轉換呢？也許對下面乙個簡單的例子的回顧能夠說服你。假設你想用sprintf 函式將乙個變數從...
關於JSON的一些總結
一 關於json json是一種類似於xml的通用資料交換格式,具有比xml更高的傳輸效率.從結構上看，所有的資料 data 最終都可以分解成三種型別 第一種型別是標量 scalar 也就是乙個單獨的字串 string 或數字 numbers 比如 北京 這個單獨的詞。第二種型別是序列 sequen...
關於指標的一些總結
指標和陣列一樣，都是基於其它型別的。指標的宣告 int p updates 運算子兩邊的空格是可選的。對每個指標變數命名，都需要乙個 變數名，為取址，它的值為變數的位址 32位 指標變數，為指標儲存的位址所儲存的值。可以通過改變它來改變。malloc 可以分配記憶體，但c 更好的方法是使用new。i...