案例1：這階段公司內部在測試乙個即將上線的產品，好幾次都遇到執行良好的服務在某個時間段後不能提供正確服務的情況，由於產品涉及到多個端，協作人員眾多，而且各端軟體的更替也較頻繁，在從內部排查問題的同時也在從外部著手確定是否有人更改過某個程式，眾研發人員都說沒有更改過程式。但是隨著排查的深入往往會發現是某個人搞混了自己發布程式的版本。
案例2：團隊中有人在發布動態庫或應用程式時採用日期來做版本號，在頻繁迭代的過程中無法使應用程式和原始碼管理系統中版本對應起來，不利於定位問題。
案例3：使用原始碼管理系統提交時為了偷懶或者忽視，不標註或隨意填寫改動描述，在進行**回退時那個費勁。
版本管理的重要性在研發工作中不言而喻，缺乏規範化在研發階段會嚴重影響開發效率，在測試階段也會造成很多無意識的錯誤，一旦到了發布階段造成的損失會更大。記得在一次公司規範管理的會議上，老總曾提到過我們的硬體產品由於燒錄程式版本的問題給公司造成了很大的經濟和聲譽損失。所以如何規範化版本管理首先作為研發人員和管理人員的我們要在心裡重視起來，進而採取措施去規範化版本。
源**和文件管理：如果你的公司還沒用原始碼管理工具進行原始碼管理，你出頭的機會就來了，向他們推薦svn和git吧（別笑，還真有很多公司沒有形成企業級的規範，我就逮到這麼乙個機會），現在據我了解大部分商業公司還是在使用svn，剛才案例3提到的提交改動描述的問題，svn就沒有git做得好，svn可以提交空注釋，於是就發現眾多偷懶的程式設計師們一片片空白的注釋，這純粹是挖坑埋自己......。提到文件，我們程式設計師最最討厭了，可是又不得不寫，用一些富文字工具寫出的文件無法進行內容比對，建議使用markdown來維護文件。
二進位制程式的管理：對於二進位制程式的版本規則，案例1給我們的教訓是必須得有，案例2告訴我們版本規則必須要能夠表達一定的含義或者對應一致的原始檔。最通用的形式通常是major.minor.build,在新版本推出時，應更新major、minor或是build的版號，決定於變更的大小。當有極大的更新時，會增加major的版號。而當有大更新，但不至於更新major時，會更新minor的版號。若更新比較小，例如只是除蟲（bug fixing），則會更新build的版號，這裡的build版本號通常可以和原始碼管理工具的revision版本號對應起來，這樣可以把應用程式和相對應的**關聯起來，在進行bug查詢或修正時是個很大的便利。
小知識:在windows下利用svn的tortoisesvn工具subwcrev.exe可以很容易獲取**的revision，配合vs的指令碼工具可以很容易的寫入程式中。 在linux環境下使用svnversion命令即可。
研發中版本管理的規範性
案例1 這階段公司內部在測試乙個即將上線的產品，好幾次都遇到執行良好的服務在某個時間段後不能提供正確服務的情況，由於產品涉及到多個端，協作人員眾多，而且各端軟體的更替也較頻繁，在從內部排查問題的同時也在從外部著手確定是否有人更改過某個程式，眾研發人員都說沒有更改過程式。但是隨著排查的深入往往會發現是...
研發中版本管理的規範性
案例1 這階段公司內部在測試乙個即將上線的產品，好幾次都遇到執行良好的服務在某個時間段後不能提供正確服務的情況，由於產品涉及到多個端，協作人員眾多，而且各端軟體的更替也較頻繁，在從內部排查問題的同時也在從外部著手確定是否有人更改過某個程式，眾研發人員都說沒有更改過程式。但是隨著排查的深入往往會發現是...
pragma的重要性和規範性
example1 pragma pack 1 include struct scmdhead head char sz systemid 36 char sz systemkey 40 int nauthoritycount 提示authority個數 std listauthoritylist s...