eclipse下SVN subclipse插件

本文目的

讓未使用過版本控制器軟件或者未使用過subversion軟件的人員儘快上手。

subversion的使用技巧不少，這裏只總結了最小使用集，即主要的基本功能，可以用來應付平常工做。

所以不涉及subversion服務器端的搭建和配置。

爲何要使用版本控制

當多人共同開發同一個軟件時，會涉及源代碼的共享以及帶來的相關問題，好比追究某個代碼是由誰在什麼時間修改的。

下面列出版本控制帶來的好處：

• 爲團隊提供了全部項目文檔的回退按鈕，我的IDE工具只能提供某個文件的回退按鈕，而不能作到，好比回退到2008年6月12日下午3點10分時的全部項目文件；
• 支持多個開發人員在可控的方式下爲相同的代碼工做；
• 版本控制系統保存了文檔在過去的各個改動，便於查找是誰，在什麼時候，由於什麼修改了文檔；
• 支持在文檔的主線上同時有多個版本（版本的分支和合並是版本控制的主要手段，一些開發團隊僅僅是簡單的共享代碼主幹）；
• 支持查詢在某個時點上項目各個文檔的狀態，可用於研究生產效率等（好比，統計項目哪一個時期代碼提交最活躍，以及每一個人的代碼提交頻次等等），也可用於對之前的軟件發行版的再發行（好比，之前構建的2.0版本的安裝包丟失了，那麼能夠經過版本控制器記錄的歷史從新回溯到那個版本，而後從新構建出安裝包）。

爲何使用subversion

首先，考慮的是使用免費開源和輕量級的版本控制器。

第二，要求使用比較普遍，可選的有cvs和svn。

這裏選擇svn，主要考慮是比較好集成apache使用，提交代碼支持原子級操做（即，好比提交3個文件，若是由於網絡或者其餘緣由，上傳2個文件後中斷，svn能作到服務器端回滾到提交前的狀態，而cvs作不到這點，須要手工檢查和恢復）。

subversion的程序構成

subversion程序，和mysql很相似，是c/s結構的，有客戶端和服務器端。服務器端和客戶端都是經過命令行方式啓動和執行的。本文只會使用到客戶端的命令。

第三方提供了各類圖形界面的客戶端工具，好比eclipse插件subclipse，windows圖形界面工具tortoiseSVN。這些後面會提到它們的基本使用。

subversion資源

• subversion官方網站：http://subversion.tigris.org/
• subclipse官方網站：http://subclipse.tigris.org/
• tortoiseSVN官方網站：http://tortoisesvn.tigris.org/
• 使用subversion進行版本控制中文版在線版本：http://www.subversion.org.cn/svnbook/

安裝subversion

有關subversion和subclise的安裝暫略，由於目前提供的虛擬機開發環境已經安裝和配置。

tortoiseSVN，可到官方網站上下載最新版本的windows安裝包，默認安裝，不須要作其餘設置，安裝後須要重啓計算機。能在資源管理器中鼠標右鍵菜單看到以下圖所示條目，就說明安裝成功。

使用subversion

平常工做中使用subversion僅僅是幾個命令或者操做，並不複雜。可是它內部的一些機制須要逐漸去理解。

檢出代碼

在剛開始進入一個開發隊伍的時候，已經有版本控制和軟件項目，使用的第一個命令每每是檢出（checkout）代碼。或者當使用和研究開源軟件的時候，也是第一個要用到這個命令。這個命令的做用是把項目的源代碼下載到用戶本地，而且帶有版本控制信息。

好比，執行如下命令獲取一個項目的源代碼：

svn co http://easymorse.googlecode.com/svn/trunk/vfs.demo/

這個命令將在本地當前目錄建vfs.demo目錄並將該服務器目錄下的全部文件下載到本地，而且，會生成隱藏文件.SVN目錄，用於記錄版本控制信息。

tortoiseSVN有圖形界面的檢出操做，可是命令行方便快捷，建議使用命令行。

若是使用eclipse並安裝了subclipse插件，能夠經過插件導入項目。

而後，

選擇或者新建資源庫位置，

選擇資源庫中的項目目錄。

而後，就能夠完成（finish）了。

初始導入

什麼時候使用初始導入，好比，對於java開發人員來講，在eclipse中編寫了一個項目，並決定把項目共享到版本控制器上，這時就須要初始導入操做了。

如下以subclipse爲例說明初始導入的步驟。

第一步，選擇share project，共享你的項目：

選擇經過svn共享項目：

填寫svn提交的url：

這個url，須要subversion的管理員告知你，還有用戶名和密碼。若是想練習一下，google提供了免費的svn，你能夠經過：http://code.google.com 申請項目，這樣就會有相似我上面的url和權限。

而後能夠直接點擊finish，完成初始提交。選擇next，能夠作定製模塊名和初始提交的信息，通常不須要。

若是你的svn服務器使用了https協議，須要接受一個數字證書，通常選擇永久接受。

以後，會要求輸入用戶名和密碼。建議勾選保存密碼，不然會很麻煩。

這樣，再看項目，會發現條目上多了問號，這時須要選擇哪些目錄和文件須要提交，哪些須要忽略，好比生成的class文件等。

選擇須要忽略的文件或者目錄，這時須要切換到導航視圖下才能看到全部文件和目錄：

從導航視圖看到的狀況：

選中須要忽略的目錄和文件，操做svn：

而後提交整個項目便可。有關提交的操做見下文。

更新項目

項目在提交前，應該先作更新項目操做。好比有一個文件a.txt，已經提交到svn中，這樣，可能有其餘用戶提交了新的改動到a.txt，你如今又修改了a.txt，準備提交你的改動。先操做更新a.txt，這樣若是該文件在svn服務器已經改動，會將改動加入到當前本地的a.txt中。

在subclipse中的操做：

提交代碼

提交代碼，通常會級聯當前目錄下全部改動的內容。

刪除代碼

對於再也不使用的代碼，能夠直接刪除掉，好比經過windows刪除文件，經過ubuntu的rm命令或者經過eclipse的delete功能，而後提交項目，subclipse會知道哪一個文件被刪除了，並將這個變化通知給svn服務器。

還原代碼

若是代碼作了改動，能夠是多個文件，也能夠刪除了文件或者新增了文件，可是沒有提交到svn服務器，能夠經過還原功能恢復到改動前的樣子。

版本的分支與合併

版本的分支和合並，是版本控制的核心功能。

好比，軟件經過版本的分支，將項目分配給多人作分工開發，經過版本合併，將這些分工實現的代碼合併到新的版本中；或者，修改代碼bug的時候，能夠先打出一個版本分支，保留出現bug的版本，好比分支版本名稱爲pre_fix_bug_2201，這裏2201表示bug的代號，而後針對這個分支作修改fix這個bug，再將修改後的內容提交到一個新的分支版本，好比post_fix_bug_2201，再到適當時候將這個分支合併到代碼主幹中去。

以上說了一下版本分支與合併的用途，這裏簡單說一下svn版本分支合併的基本原理。

首先是版本分支，其實是將當前版本「copy」到分支上，很是相似windows下，將某個目錄的快捷方式複製到其餘路徑。這種copy，能夠說是輕量級copy或者叫廉價copy，不是複製版本內容，而是作一個內部的引用。這樣的copy很快，對服務器也沒有空間上的開銷。

版本的合併，是svn開發中的難點，當作版本合併的時候，服務器會試圖智能的合併同一個文件的不一樣版本，可能會帶來版本衝突，這須要操做者作手工的處理，消除版本衝突。合理分工的項目應該能夠經過管理手段儘可能避免這種狀況。

如下是經過subclipse演示版本分支的操做。首先，項目文檔應該已經所有提交，而後，選擇

而後，填寫url，通常是在tags/目錄下：

而後默認選項，next便可，而後選擇finish按鈕。在svn的相應路徑下就會有一個同名的項目。

打分支，實際上就是創建了一個項目的輕量級copy。

如何從版本的一個分支切換到另一個分支，這也是很重要的，它能幫助你輕鬆在不一樣的項目版本中自動切換，而沒必要在eclipse裏維持多個項目。

選擇要切換的項目版本路徑，或者直接輸入亦可。

 

而後點擊ok後，項目便可切換到該版本下。

在分支上作了改動，而且已經提交（通常tags目錄下的項目約定是隻讀的，不建議改動，這裏是爲了舉例方便），那麼，能夠將這個版本合併到trunk（主幹）代碼中，讓主幹也擁有最新的代碼。

 

選擇須要合併的源，好比從tags上面一個版本，合併到主幹（trunk）代碼中。

以後，須要設置一些合併的特性，這裏默認配置便可。

執行完畢後，會有一個合併報告，可見沒有出現衝突狀況。

這時候看源代碼，能夠發現有改動，這些改動就是合併過來的代碼。

改動若是沒有問題，就能夠提交，這樣就完成了一次版本的合併工做。

 

 

「還原」已經提交的改動

若是文檔沒有提交，還原是很容易的，只需執行還原（revert）就能夠了。有時候，已經提交了代碼，結果發現了問題，須要回退到以前提交的版本，就不是很容易了。

這時候的還原，實際上是將之前的某個修訂本（revision）覆蓋當前的本地工做拷貝。而後再提交這些改動，成爲新的修訂本。

下面演示一下。

首先提交了一個版本的改動，這是之後須要還原回來，這裏，爲了之後還原方便，要在提交的消息中說明改動了什麼。（這一步在開發中是必須的，是紀律）

下面，再修改一下項目，而後提交一次，這裏故意增長一個文件。

提交之後，後悔了，想恢復到前一個修訂版。雖然能夠經過版本號進行覆蓋還原，可是通常人是沒法記憶這個版本號的，另外就是實際狀況每每更復雜，不會像示例中那樣是相鄰的兩個修訂版。

因此提交修訂版時的註解消息就顯得特別重要。

這時能夠經過svn的日誌功能查看到這些版本和它們的註釋消息。

看到歷次版本的消息內容。

這樣，根據註釋，咱們很容易找到須要還原到之前的那個修訂版。若是不放心，咱們還能夠根據上下文菜單，對比兩個修訂版的區別。

看比較結果。能夠看出，增長了一個文件，另一個文件中有一處差別。

那麼，能夠肯定是從125修訂版恢復（還原）。

更改後的項目，至關於用125修訂版還原了126修訂版。

能夠看到126版本添加的文件不見了，另外VfsDemo.java文件也還原到125版本的內容。這時提交將成爲127版本，這個版本其實就是125版本。算是還原了主幹（trunk）上的代碼。

刷新歷史，能夠看到修訂版已經生效。

 

轉載於：http://www.cnblogs.com/chencidi/articles/1904781.html