demoshop

demo, trying to be the best_

SVN 每次送交的時候都會存有一份 Log 包含了異動的檔案清單和Developer 自行撰寫的文字說明,這些 Log 記錄了相當豐富的資訊如果可以拿來運用是不是很棒呢(我想只有主管會說棒吧...)
 

前面介紹到可以將 SVN Server 設定成有成員送交(Commit)就發信提醒,這對於多人開發的情況是很重要的,但是如果你今天使用的是業主、教授的 SVN Server ,而他們並沒有做這種設定,又無法逼他們一定要去處理的時候只好換個方式自力更生了。

上一篇提到了如何限制使用者送交沒有 Log 的檔案,其中用到的一些觀念(雖然我都沒說)也可以進一步讓使用者送交後會發信告知特定使用者或群組,這種發信的機制對於多人開發是一個很好的事情,因為這樣才可能知道別人在改什麼,才能了解專案的大致進度,為了達成這功能你還是必須要可以碰到 SVN Server,如果你碰的到那就看下去吧。
 

版控介紹到這裡這裡各位應該都可以體會 Log 是一個非常重要的東西,分支、合併、還原、刪除等等一堆功能都需要靠 Log 來做判斷,但是預設的情況下 Log 是可以不輸入的,對於這種不輸入 Log 的送交實在是很頭痛,因此這裡就來介紹如何強迫每次送交(Commit)都需要寫 Log 的方式。

前面介紹了很多關於 TortoiseSVN 的應用,不可諱言 TortoiseSVN 真的是一套不可多得的好軟體,但是對於 .NET 開發人員來說,每天都開者 Visual Studio 難道就沒有一個比較聰明的整合工具嗎?每次都還要到外面去送交檔案就是那麼的不方便!因此這裡就介紹兩款數一數二的 Visual Studio For SVN 工具。

前面介紹了許許多多有關於 SVN Client 軟體 TortoiseSVN 的使用方式(其實只是 SVN 的 GUI 呈現而已),相信對於 TortoiseSVN 的操作上已經是沒有什麼問題了,這篇是 TortoiseSVN 的最後一篇,因此要在來介紹一些小技巧,這些小技巧並不影響版控的操作,但是知道以後可以更快速的完成一些工作,記下來絕對是有很大的幫助的。

Tag 這玩意顧名思義就是一個標籤,用起來沒有什麼技巧,就是用而已,所以 demo 想提一下為什麼要做 Tag,當專案或是文件寫到一定程度時一定會有交付的需求產生,雖然版控可以隨時回到指定版本來發佈或交付,但還要去回想我這次要交付的進度是哪一個版本,或是你要比對上次交付的版本和這次交付的版本差異在哪的時候就會變得很麻煩,因此 Tag 功能的用處就出現了,當你交付了一次版本後就將這版本建立一個 Tag,往後你想比對、想拿出來修改就都不會是問題,對於寫程式來說經常會發生當初專案是使用 v2.0 的Library寫的,一陣子後 Libray 已經修改到 v5.0了,而且無法向下相容這時候要去改用 v2.0寫的專案就會變得很麻煩,如果你有用 Tag 那就可以立即找出 v2.0的最終發行版立即修改解決問題,所以 Tag 也可以算是一個方便的技巧。

前面介紹了合併主線異動到分支的方式熟悉了以後,應該對於分支的進展有很大的幫助,終於分支的功能開發也已經完畢了,在確定程式正確無誤後就要將分支的這些異動合併回主線去,擴充主線的功能,因此這章就是要說明如何合併分支的異動回歸到主線。

前面說到分支(Branch)與主線(Trunk)是完全隔離的,分支(Branch)的異動並不會影響主線(Trunk),反過來主線(Trunk)的變動也不會滲透到分支內,這是前一篇在在提分支(Branch)的時候一直強調的概念,但這會造成一個問題!

利用分支(Branch)的功能可以有效隔離主線(Trunk),當開發程式時想重構、測試寫法、開發新功能,這些動作可能不會那麼快處理完畢,並且在調整的同時,可能會造成現有功能發生錯誤,以上這種行為都應該在分支(Branch)下執行,當你一切功能與測試都通過確認後再合併主線(Trunk)就可以大幅降低在開發時期對主線(Trunk)的影響,更棒的是 SVN 的分支是屬於廉價複製,也就是說在版本庫中並不會存在兩份資料有效節省空間的使用,以下舉個實際的例子
 

在多人開發的環境下,應該難免會遇到程式更新後馬上就編譯不過,或是有人改了原本自己負責的部份卻造成了 Bug 讓自己受到莫名之冤,以往只能大叫「X 誰改我的程式」然後一定不會有人跳出來說話,現在不一樣了,因為團隊中使用了版控,還記得之前說的嗎,版控會記錄你從第一版開始到現在所有的變更,當然也會記住是誰改了你的程式….而且使用方式超級簡單,算是一個一招定生死的工具
 

在受到 Subversion 版控保護的時候都會在每層的資料夾中擁有 (.svn | _svn) 資料夾,前文有提過千萬不要修改這資料夾的內容,避免版控發生難以拯救的災難,但專案寫完了、工作完成了後總是要交付吧,交付的時候怎麼可能把這有(.svn | _svn) 資料夾的檔案給人,自己刪除?別鬧了!有些資料夾相當的深,每一層都有你會砍到死的。
 

在【TortoiseSVN 使用,從 Repository 抓取特定版本程式(Update)】一文中有提到回覆到之前版本的功能,雖然這種功能已經可以讓時光回逤到一定的點,可是有種情況之下是不適用滴。

在版控系統中任何的異動都會造成一個版本,這是很基本的觀念,版控中對於「移動」和「更名」這些很自然的基本操作確有者一些特殊的操作流程,目的只是為了保留版本歷史記錄,剛開始接觸到的時候很容易做錯或者根本不知道有錯,因此本篇會來介紹版控中「移動」和「更名」的使用方式。
 

一般來說使用更新(Update)都會是取最新版,但是在某些情況之下會需要取回某一次的版本,發生了這種需求的時候只需要將版本更新(Update)至某一版本即可(可以理解成回復)以下就是示範。

上一篇介紹了解決衝突的辦法,但是有個前提就是更新(Update) 的畫面不能關掉,可是這前提實在是太困難了,這視窗很容易就隨手關了,所以又有了這一篇,說明如果已經關閉更新(Update)視窗後要如何排除衝突。
 

上一篇介紹了完美的更新(Update)是如此的輕鬆簡單,基於之前【 Subversion 版本控管的基礎概念】的介紹因為有了自動合併這件事情,所以在 Subversion 內絕大多數都會是那麼完美的,但是如果真的遇到了衝突呢?
 

介紹完了送交(Commit)再來就是更新(Update)的用法,前文也一直有提到當專案有成員送交(Commit)了任何異動,其他成員就必須使用更新(Update)才能取得新檔案,所以更新(Update)也是另一項經常使用的功能,而且他相當簡單。

上一篇介紹了送交(Commit) 的作法看似很簡單,但是還是有些觀念要說明,因此才有了這一篇的出現,在我們開始使用版控以後對於一些平常的習慣需要改變一下,為的是不要讓檔案庫(Repository)髒掉,並且讓其他成員可以了解到每次的送交(Commit)是做了什麼以及為什麼。
 

接續者上一篇,在我們將檔案庫(Repository)的檔案複製一份到工作目錄後,再來就會去修改這工作目錄中的檔案,在  Subversion 內檔案異動後必須要送交(Commit)其他成員以及檔案庫(Repository)才會知道這次的異動,本篇就要介紹如何送交(Commit)檔案。