版本控制是企業開發中乙個老生長談的主題,這也是大部分公司新人進來後需要接納的乙個基礎知識體系.
從08年首次接觸商業軟體編寫後,這幾年先後接觸了svn,tfs,git這幾個主要的版本控制器,但是並沒有深入的去研究過包含的思想,
因此下文只能簡單描述自己使用這些主流的版本控制的感受.
接觸svn時,對軟體開發還是門外漢,大約只是圖個新鮮,當初大約有10個人在同乙個responsite下寫**,只不過每個人都只做自己的頁面,互相不干涉,這樣用了
一年多的時間,我都沒有接觸過更高深的理念,唯一知道的是,改錯**可以從伺服器上找回來,這也是對其最初的印象.
進公司時,部門是用的tfs,當初有點逆反心理,覺得我會svn了,為什麼還是要學tfs呢,於是在不是特別情願的情況下先看了一段時間的tfs,對它重視起來是由於自己的乙個不小心,
從伺服器check out時,覆蓋了自己的改的一些**,當時是非常沮喪啊,那幾行業務**前後改了1個月,吸取了教訓後,對tfs的心理排斥就沒有了.不過我個人覺得它的缺點有2個:
1:tfs服務端我曾嘗試自己建立乙個,但是對機器環境的要求比較高,嘗試失敗後,就放棄了
2:客戶端也挺龐大的,那時還是用的筆記本,感覺好卡
12年時,部門專案全部轉移到git上開發,和初接觸tfs一樣,我也是沒有太在意這些,同事簡單的告訴我幾個命令後,也沒有體會到主管說的分布式開發的內在,當時的心理想法是
覺得你們愛折騰就去折騰,隨著專案的推進,有時會遇到多人工作同乙個頁面的可能性,在沒搞懂git時,發版本經常會出現已修復的bug又存在下乙個版本中,非常糾結啊,當時為乙個事故,被直屬主管,部門主管,公司領導
依次批評了一頓,所以說很多時候吃虧就是在一些小事情上.現在對git的使用已經比較熟練了,也越來越懂它的強大之處.
它的優勢在於相對tfs而言,部署比較簡單,有一段時間,我部署在自己機器上,後來發現bitbucket這個**後,就全轉移到上面了,個人覺得開發人員積累自己獨立的專案庫還是應該的.
下面貼一張我目前開發silverlight專案的圖:
第1步到第2步,是git基本的使用,第3步到第4步,是發行版本後,需要修復bug,第4步到第5步,是2個分支修改bug同步.寥寥數語,如果對git比較熟悉的話,
我想這張圖很好解釋,相比git官方提供的流程圖,省去了一些過程.
對於它的深入理解: 請參考
關於版本控制器,裡很多人研究的很深很細,而我只是略懂皮毛,對上面3個版本控制器的評價主要還是停留在個人感受上,不過相比較而言,我更為推薦的
git了,希望沒有用過的朋友可以感受下強大之處.
Silverlight的4個版本
silverlight出了至少4個版本以上,但是並沒有在版本號上進行更新,最新版本還是1.0的version info顯示是1.13版本,而silverlight1.1 alpha也有兩個不同大小的版本,乙個是4.5m左右,乙個是4.6m左右,加上1.0的早期版本,一共是4個版本了 如果你安裝了1....
版本控制 設計模式 模式版本控制
版本控制 設計模式 schema versioning changing a namespace is not versioning,it is new type creation.meta douglasp 架構版本控制 更改命名空間不是版本控制，而是建立新型別。meta douglasp ok....
SVN版本控制
1.svn安裝 sudo apt get install subversion 2.建立倉庫 對於多個 倉庫 首先在 var 下建立svn主目錄。svnadmin create var svn test1 svnadmin create var svn test2 3.修改配置檔案 倉庫目錄下 co...