SVN管理規(guī)范方案.doc

《SVN管理規(guī)范方案.doc》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。

1、Subversion管理規(guī)范一Subversion介紹Subversion(Subversion)是一個(gè)時(shí)間機(jī)器，隨時(shí)記錄文件和目錄的每次改動(dòng)，例如：文件的增加、刪除、重新排列文件等。同時(shí)SUBVERSION允許你恢復(fù)以前舊版本的數(shù)據(jù)，或者檢查數(shù)據(jù)變化的歷史。SVN使用類似數(shù)據(jù)庫事物的方式來處理用戶提交入庫的過程，整個(gè)改動(dòng)要么成功的被提交，要么被中斷并回滾。在數(shù)據(jù)提交完之前，其他人是看不到用戶提交的修改文件，你看到的要么是改動(dòng)之前的狀態(tài)，要么是改動(dòng)之后的狀態(tài)。這樣的行為被稱為“原子提交”4。原子提交很有用，因?yàn)樗鼙ＷC所有相關(guān)人員看到的總是相同的東西。原子提交過程的其中一步就是包

2、括把你的所有改動(dòng)打包為一個(gè)“修訂集”（有時(shí)被稱為改動(dòng)集），并且再給個(gè)改動(dòng)標(biāo)記的修訂號(hào)（綠色勾變?yōu)榧t色嘆號(hào)）。WorkingCopyWorkingCopyRepositoryNetwork版本庫網(wǎng)絡(luò)本地工作副本檢出、提交圖1圖1總體概括了SVN整個(gè)操作過程：首先用戶從版本庫通過網(wǎng)絡(luò)“檢出”到本地工作副本中，然后，在本地工作副本中進(jìn)行增加、修改、刪除文件后“提交”到版本庫中，如果本地工作副本中版本較系統(tǒng)版本過時(shí)，用戶使用“更新”功能與系統(tǒng)上版本保持一致。二Subversion的目錄結(jié)構(gòu)每個(gè)SVN版本庫下需要有trunk(可用項(xiàng)目名做目錄名)、branches及tags目錄，trunk

3、表示開發(fā)時(shí)版本存放的目錄，即在開發(fā)階段的代碼都提交到該目錄上。branches表示發(fā)布的版本存放的目錄，即項(xiàng)目上線時(shí)發(fā)布的穩(wěn)定版本存放在該目錄中。tags表示保存測(cè)試無問題的發(fā)布版本，不可修改。branches/tags命名規(guī)則：項(xiàng)目名[_說明]_版本號(hào)。在這需要說明下分三個(gè)目錄的原因，如果項(xiàng)目分為一期、二期、三期等，那么一期上線時(shí)的穩(wěn)定版本就應(yīng)該在一期完成時(shí)將代碼copy到branches上，這樣二期開發(fā)的代碼就對(duì)一期的代碼沒有影響，如新增的模塊就不會(huì)部署到生產(chǎn)環(huán)境上。而branches上的穩(wěn)定的版本就是發(fā)布到生產(chǎn)環(huán)境上的代碼，如果用戶使用的過程中發(fā)現(xiàn)有bug，則只要在bran

4、ches上修改該bug，修改完bug后再編譯branches上最新的代碼發(fā)布到生產(chǎn)環(huán)境即可。tags的作用是將在branches上修改的bug的代碼合并到trank上時(shí)創(chuàng)建個(gè)版本標(biāo)識(shí)，以后branches上修改的bug代碼再合并到trunk上時(shí)就從tags的version到branches，最新的version合并到trunk，以保證前期修改的bug代碼不會(huì)在合并。4三說明注釋對(duì)SVN的日常文件更新一律按照“檢出---提交”的方法，用戶需要在本地建立工作副本，每次在本地修改后提交到SVN服務(wù)器上，不允許直接將文件拖拽到服務(wù)器上。用戶在提交日常文件成功后，系統(tǒng)會(huì)自動(dòng)精確到秒的記錄用

5、戶所有操作。因此，用戶在日志備注中應(yīng)注明提交原因和較詳細(xì)的描述修改的地方，以便日后整理補(bǔ)丁回滾版本所需。日常更新的文件、數(shù)據(jù)不能設(shè)置密碼；文件、數(shù)據(jù)不允許重復(fù)放置。如下所示：+)?表示增加了功能*)?表示對(duì)某些功能進(jìn)行了更改-)?表示刪除了文件，或者對(duì)某些功能進(jìn)行了裁剪，刪除，屏蔽。b)?表示修正了具體的某個(gè)bug四提交規(guī)則提交之前先跟新在更新時(shí)注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則也是需要重新編譯并且完成自己的一些必要測(cè)試，再進(jìn)行提交。這樣既能了解別人修改了哪些文件，同時(shí)也能避免SVN合并錯(cuò)誤導(dǎo)致代碼有錯(cuò)。如果在修改的期間別人也更改了svn的對(duì)應(yīng)文件，那么commi

6、t就可能會(huì)失敗。如果別人和自己更改的是同一個(gè)文件，那么update時(shí)會(huì)自動(dòng)進(jìn)行合并，如果修改的是同一行，那么合并時(shí)會(huì)產(chǎn)生沖突，這種情況就需要同之前的開發(fā)人員聯(lián)系，兩個(gè)人一起協(xié)商解決沖突，解決沖突之后，需要兩人一起測(cè)試保證解決沖突之后，程序不會(huì)影響其他功能。負(fù)責(zé)謹(jǐn)慎的提交自己的代碼當(dāng)某一模塊功能完成后，并測(cè)試無問題，謹(jǐn)慎地提交。如果提交過程中產(chǎn)生了沖突，則需要同之前的開發(fā)人員聯(lián)系，兩個(gè)人一起協(xié)商解決沖突，解決沖突之后，需要兩人一起測(cè)試保證解決沖突之后，程序不會(huì)影響其他功能。如果提交過程中產(chǎn)生了更新，則也是需要重新編譯并且完成自己的一些必要測(cè)試，再進(jìn)行提交。?不要提交自動(dòng)生成的文件M

7、yEclipse會(huì)在build、.setting和根目錄下生成大量編譯及工作空間信息文件，不要把這些文件提交。盡量做到每次提交選擇確認(rèn)提交的文件提交，而非點(diǎn)擊根目錄提交，并把所有文件勾選上。不要提交不能通過編譯的代碼4代碼在提交之前，首先要確認(rèn)自己能夠在本地編譯。如果在代碼中使用了第三方類庫，要考慮到項(xiàng)目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫或者沒有放入jre的ext中，項(xiàng)目人員在準(zhǔn)備項(xiàng)目工作區(qū)域的時(shí)候，需要考慮到這樣的情況，確保開發(fā)小組成員在簽出代碼之后能夠在統(tǒng)一的環(huán)境中