更換 Linux 核心是每一位 Linux 主機管理者經常要面對的問題, 本文將一些文件串聯在一起, 供各位參考
更換 Linux 核心(Kernel) 對剛接觸 Linux 管理者而言, 多少會覺得有點困難; 其實只要試個幾次, 很快地, 您就會感到駕輕就熟.
早期更換 Linux Kernel 只有採用原始碼編譯一途, 近幾年由於套件管理模式大行其道, 因此又多了另一新選擇, 其中 RPM 是最為流行的方式之一.
注意! 不管您打算採用那一種方式, 您都應該先做好一開機片, 以防萬一
製作開機片的方法如下:
1.
uname -r
比如出現以下訊息
2.4.18-10
2.
將它放在以下指令之後, 此時請放入一片空白磁片:
mkbootdisk --device /dev/fd0
完整指令為:
mkbootdisk --device /dev/fd0 2.4.18-10
接著您便可以安心來做核心的更換工作了.
以下先介紹原始碼編譯安裝的方法:(by OLS3 技術文件)
一. 原始碼 Kernel 重製:
流程:
1.
先至 ftp.tnc.edu.tw/sysop/Linux-kernels/
或 http://www.kernel.org 去下載 Linux 核心
其中, 版本代碼 2.4 開頭者為穩定版(建議), 2.5 為實驗版(不建議).
2.
設定 kernel 選項
3.
編譯 kernel
4.
編譯 modules, 安裝 modules
5.
安裝 kernel
6.
設定 boot loader
7.
重新開機
步驟:
1.
cd 您解壓後的目錄下的 linux 目錄中
2.
make mrproper
3.
make xconfig (menuconfig 或 config), 它會存成 .config
這個步驟是最困難的, 因為您必須了解很多個選項的意義才行! 這個部份也是必須充份練功的地方!
4.
make dep
5.
make bzImage
6.
make modules
7.
make modules_install
8.
cp arch/i386/boot/bzImage /boot
9.
編輯 /etc/lilo.conf 或 /boot/grub/grub.conf
lilo.conf 的修改範例:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
linear
default=linuxnew
image=/boot/vmlinuz-2.2.14-5.0
label=linux
read-only
root=/dev/hda1
image=/boot/bzImage
label=linuxnew
read-only
root=/dev/hda1
==========================
grub.conf 的修改樣本:
default=0
timeout=3
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.18-10)
root (hd0,0)
kernel /vmlinuz-2.4.18-10 ro root=/dev/hda3
initrd /initrd-2.4.18-10.img
title Red Hat Linux (2.4.18-5)
root (hd0,0)
kernel /vmlinuz-2.4.18-5 ro root=/dev/hda3
initrd /initrd-2.4.18-5.img
title Red Hat Linux (2.4.18-3)
root (hd0,0)
kernel /vmlinuz-2.4.18-3 ro root=/dev/hda3
initrd /initrd-2.4.18-3.img
10.
執行 lilo -v -v; 若是使用 grub, 則不必.
11.
reboot
*
為安全起見, 應該在 lilo 中保留舊核心, 以免萬一新核心出問題, 而無法開機.
說明:
1.
make mrproper 會移除先前重製核心時不必要的殘餘檔案, 這樣可以避免這些檔案對原始碼目錄樹產生不必要的干擾. 執行 make mrproper 時, 會砍除設定配置檔 .config, 如果您認為它很重要的話, 應該予以備份.
2.
make config 是文字選項模式, 也是傳統的方式, 這個方式的缺點是: 在選擇時, 無法回頭.
make menuconfig 是文字選單模式.
make xconfig 是圖型選單模式, 需要 X Windows.(推薦此方式)
make config 時, 它會先執行 /bin/sh scripts/Config arch/i386/config.in
二. 使用 RPM 更換核心:
必須注意您的硬碟是 IDE 或是 SCSI, 以及您的主機 CPU 是單顆或雙顆!
另外, 我建議各位在更換核心之前, 先安裝 urh, 把大部份套件自動予以更新, 它也會把核心相關的 RPM 更新, 如 kernel-header*.rpm; 俟 urh 執行完畢, 才來進行以下動作!
A. 若是 IDE 硬碟, 那麼更換的方式十分簡單:
1. 若有安裝 autoURPM(ftp.tnc.edu.tw/sysop/urh) 者,
可 cd /var/spool/autoupdate
rpm -ivh kernel-2.2.19-6.2.16*.rpm
若無安裝 autoURPM 者,
可至教網中心 ftp.tnc.edu.tw/sysop/rpms 中去下載
kernel-2.2.19*.rpm
若是雙 CPU , 則要安裝 kernel-smp*.rpm 的套件.
2. 編輯 /etc/lilo.conf 修改成如下:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
linear
default=linuxnew
image=/boot/vmlinuz-2.2.14-5.0
label=linux
read-only
root=/dev/hda1
image=/boot/vmlinuz-2.2.19-6.2.16
label=linuxnew
read-only
root=/dev/hda1
注意! 您的開機區未必是 /dev/hda1
必須視貴校主機 lilo.conf 中原有的設定而定
3. lilo -v -v
4. 重新開機即可.(注意, 上述已改由新的核心來開機)
若是使用 GRUB 來開機者, 只要執行以下指令即可
rpm -ivh kernel-2.2.19-6.2.16*.rpm
不必再去修改 /boot/grub/grub.conf
因為安裝這個 kernel RPM 套件時, 它會自動幫您修改 grub.conf
您唯一要做的是: 把 grub.conf 中的開機順序改成新的核心
比如: 以下的 default=0 即表示是由最新的 kernel 來開機
default=0
timeout=3
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.18-10)
root (hd0,0)
kernel /vmlinuz-2.4.18-10 ro root=/dev/hda3
initrd /initrd-2.4.18-10.img
title Red Hat Linux (2.4.18-5)
root (hd0,0)
kernel /vmlinuz-2.4.18-5 ro root=/dev/hda3
initrd /initrd-2.4.18-5.img
title Red Hat Linux (2.4.18-3)
root (hd0,0)
kernel /vmlinuz-2.4.18-3 ro root=/dev/hda3
initrd /initrd-2.4.18-3.img
B. SCSI 硬碟:
若是 SCSI 硬碟, 且 /boot 中有 initrd 的 image
則要多做一個動作: (註: 若您是安裝 RedHat 7.2 以後的版本,
可直接像 IDE 硬碟的作法一樣,
使用 rpm -ivh kernel*.rpm 即可升級)
以 RedHat 6.2 為例:
mkinitrd /boot/initrd-2.2.19-6.2.16.img 2.2.19-6.2.16
lilo.conf 要修改, 加入以下設定:
image=/boot/vmlinuz-2.2.19-6.2.16
label=linuxnew
root=/dev/sda1 (這個地方, 要視您原先的 root=/dev/sda?? 而定)
initrd=/boot/initrd-2.2.19-6.2.16.img
read-only
再 lilo -v -v
重新開機一次
當然, 開機 bootdisk 一定要先準備好.
若還是不成?, 可用 RedHat 7.3 光碟直接升級.
再用 urh-7.3 來大量升級套件. (下載位址: ftp.tnc.edu.tw/sysop/urh)
(以上是 OLS3 在網管討論區的回應)
C. 以下問題您可能也會碰到喔!(SCSI硬碟)
底下是敝縣網管討論區中二位網管先進的對話內容節錄, 對您可能有所幫助.
=======================
sammy 留言:
重新開機後出現LI
二字就都不動了
還好我有做舊kernel的開機片,
暫時用開機片開機server可工作
我的猜測是 lilo -v -v時
電腦以為我的開機碟是hda,
所以把開機程式寫入hda,但我真正的開機碟是sda
但實際情形是否如此,我也不知
目前暫時只能用磁片開機
請問要如何是好
========================
hsmhsm 回覆 sammy 如下:
之前去中山上課,老師說ide的硬碟就是會先被讀取
所以他在前兩行中間再加了兩行
(不過當時裝的是trustix)
boot=/dev/sda
disk=/dev/sda
bios=0x80
map=/boot/map
反正你有開機片,要不要試試??
=======================
sammy 回覆 hsmhsm 如下:
從暑假一直放到現在,
放了一個月,一直使用開機片開機
今天終於有空試了一下
在加了那二行後,
果然成功,真是謝了
摘自:http://www.csie.nctu.edu.tw/~tsaiwn/course/introcs/history/linux/linux.tnc.edu.tw/techdoc/kernel2.html
2009年5月14日 星期四
2009年5月12日 星期二
[ecplise]java.lang.OutOfMemoryError: Java heap space
with the increased parameters from Ed I did not yet receive a dump.
So currently me eclipse.ini looks like the following:
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
512m
-vmargs
-Xms40m
-Xmx512m
-XX:+HeapDumpOnOutOfMemoryError
So currently me eclipse.ini looks like the following:
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
512m
-vmargs
-Xms40m
-Xmx512m
-XX:+HeapDumpOnOutOfMemoryError
2009年5月7日 星期四
I'm managing a website in my repository. How can I make the live site automatically update after every commit?
This is done all the time, and is easily accomplished by adding a post-commit hook script to your repository. Read about hook scripts in Chapter 5 of the book. The basic idea is to make the "live site" just an ordinary working copy, and then have your post-commit hook script run 'svn update' on it.
In practice, there are a couple of things to watch out for. The server program performing the commit (svnserve or apache) is the same program that will be running the post-commit hook script. That means that this program must have proper permissions to update the working copy. In other words, the working copy must be owned by the same user that svnserve or apache runs as -- or at least the working copy must have appropriate permissions set.
If the server needs to update a working copy that it doesn't own (for example, user joe's ~/public_html/ area), one technique is create a +s binary program to run the update, since Unix won't allow scripts to run +s. Compile a tiny C program:
#include
#include
#include
int main(void)
{
execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
(const char *) NULL);
return(EXIT_FAILURE);
}
... and then chmod +s the binary, and make sure it's owned by user 'joe'. Then in the post-commit hook, add a line to run the binary.
If you have problems getting the hook to work, see "Why aren't my repository hooks working?".
Also, you'll probably want to prevent apache from exporting the .svn/ directories in the live working copy. Add this to your httpd.conf:
# Disallow browsing of Subversion working copy administrative dirs.
Order deny,allow
Deny from all
from:http://subversion.tigris.org/faq.html#website-auto-update
In practice, there are a couple of things to watch out for. The server program performing the commit (svnserve or apache) is the same program that will be running the post-commit hook script. That means that this program must have proper permissions to update the working copy. In other words, the working copy must be owned by the same user that svnserve or apache runs as -- or at least the working copy must have appropriate permissions set.
If the server needs to update a working copy that it doesn't own (for example, user joe's ~/public_html/ area), one technique is create a +s binary program to run the update, since Unix won't allow scripts to run +s. Compile a tiny C program:
#include
#include
#include
int main(void)
{
execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
(const char *) NULL);
return(EXIT_FAILURE);
}
... and then chmod +s the binary, and make sure it's owned by user 'joe'. Then in the post-commit hook, add a line to run the binary.
If you have problems getting the hook to work, see "Why aren't my repository hooks working?".
Also, you'll probably want to prevent apache from exporting the .svn/ directories in the live working copy. Add this to your httpd.conf:
# Disallow browsing of Subversion working copy administrative dirs.
Order deny,allow
Deny from all
from:http://subversion.tigris.org/faq.html#website-auto-update
2009年4月23日 星期四
CSS分頁語法–page-break-after
web列印分頁,一般使用css属性page-break-after/page-break-after,在需要分頁的地方可以插入標籤
pageBreak css如下:
.pageBreak{
page-break-after:always;
}
但在使用的时候,可能會碰到IE能正常分頁,但Firefox却没有任何效果。經分析,在Firefox中使用page-break-after屬性時,不能像所有的列印内容都放在一個表中。也就是說Firefox是不能將表斷開的。所以在Firefox中使用page-break-after進行分頁列印,要避免將列印的内容放在一個表中,替代的方法是可以将内容放在一個DIV中。
摘自:http://ziwei888.wordpress.com/2009/03/02/css%E5%88%86%E9%A0%81%E5%95%8F%E9%A1%8C-page-break-after/
pageBreak css如下:
.pageBreak{
page-break-after:always;
}
但在使用的时候,可能會碰到IE能正常分頁,但Firefox却没有任何效果。經分析,在Firefox中使用page-break-after屬性時,不能像所有的列印内容都放在一個表中。也就是說Firefox是不能將表斷開的。所以在Firefox中使用page-break-after進行分頁列印,要避免將列印的内容放在一個表中,替代的方法是可以将内容放在一個DIV中。
摘自:http://ziwei888.wordpress.com/2009/03/02/css%E5%88%86%E9%A0%81%E5%95%8F%E9%A1%8C-page-break-after/
Subversion 實務建議
實務 1. 備份檔案庫
一旦你使用了 Subversion 來管理版本,檔案庫就成為你開發時最重要的資產之一了,因此最好利用排程工具,定期將檔案庫備份,如果你的檔案庫都放在一個統一的目錄下,例如:d:/svn,就只要完整備份這個目錄就行了。
--------------------------------------------------------------------------------
實務 2. 盡量熟悉命令列工具
儘管你大部分時候都是使用視覺化工具(例如:TortoiseSVN)來執行版本控制的日常工作,熟悉命令列工具仍然非常有用,特別是當你要執行一些批次作業時。
--------------------------------------------------------------------------------
實務 3. 建立測試環境
有些團隊可能是用 nightly build 或 weekly build 的建置方式,然後對新建置的版本進行測試,這種方式可能是由專人負責建置,然後把新版的程式部署到測試機器上。
另一種可能的情況是,測試人員隨時都可以測試最新版的程式,也就是每當程式修改好,check in 到檔案庫之後,測試人員就要能測到最新版的程式。這種需求可以透過在測試機器上建立排程來達到,排程的工作是執行一個批次檔,而這個批次檔裡面就是些 Subversion 的 update 命令。例如:
REM 此批次檔用來更新測試機器的程式檔案
c:
cd\MyProject\BookWeb\BookWeb.war
svn update -N
cd Image
svn update
cd ..
cd Script
svn update
cd ..
cd Jsp
svn update
cd ..
cd WEB-INF\classes
svn update
cd ..\lib
svn update
cd ..
這種方式要注意一個問題,就是測試機器上的應用程式目錄裡面,每個目錄都會有一個隱藏的 .svn 目錄。如果要把測試機器上的檔案部署到用戶端,並且排除 .svn 目錄,就要使用 Subversion 的匯出(export)功能。
--------------------------------------------------------------------------------
實務 4. 只 check in 完成的檔案
程式還有編譯錯誤及警告時,不要 check in 到檔案庫。一方面是基於測試的理由(程式當然是可以運作才放上去測試),另一方面,是因為這樣做可能會對別人造成困擾,因為別的開發人員可能有將整個專案的程式碼取出,那麼每當他在本機上建置專案時,就會出現一堆編譯錯誤,包括他自己的程式和你的程式的錯誤。如果每個人都在程式還未能通過編譯時就 check in,那麼每次編譯專案產生的錯誤訊息將多到令人無法忍受。
--------------------------------------------------------------------------------
實務 5. 每次 check in 時,輸入摘要事項
每當我們要 check in 檔案時,Subversion 會要求我們輸入一段文字,用來簡單說明這次 check in 做了哪些改變。你可以把重要的備註事項寫進去,以後如果要回頭比對版本,可以幫助你更找到需要的版本。
--------------------------------------------------------------------------------
實務 6. 不要保留沒用的註解
以往沒有版本控制時,我們在修改程式時,常常會把一段程式碼註解掉,以便日後反悔時,可以恢復。但是這類註解掉的程式碼往往會一直留在那裡,直到程式改了好幾個版本,已經沒有利用價值以後,成為程式裡的一堆礙眼的垃圾。
有了版本控制以後,因為可以隨時回到任一個歷史版本,你可以放心的把不要的程式碼刪除,再配合實務 5,以後要恢復歷史版本就很容易了。
--------------------------------------------------------------------------------
實務 7. 不要留下多餘的檔案
以往沒有使用版本控制系統時,我們有時候會自己做一點版本管理,例如修改 Foo.java 之前,先把它複製成一個新的檔案,並且加上序號,例如:Foo_1.java,然後再修改 Foo.java。現在有了版本控制系統,可以不用這樣了,免得多了一堆垃圾檔案。
我曾看過一種情況,就是有人還是習慣用附加編號的方式自己備份舊版的檔案,而且跟新版的檔案放在同一個目錄下,另一方面,他又習慣把程式的檔名用序號來命名(懶得想個適切的檔名),結果備份的檔名和開發中的檔名都是用序號來命名,有一天某人要清理專案目錄中的垃圾時,就把所有帶序號的檔名都砍了,造成程式無法編譯或執行。還好我們有時光機器可以回到過去,要不然就麻煩了。
--------------------------------------------------------------------------------
實務 8. 檔名大小寫第一次就決定好
如果你的作業系統不區分檔名的大小寫,例如:Windows,你最好第一次就把檔案名稱的大小寫確定下來。否則如果日後要改檔名,而且新的檔名和舊的檔名只有大小寫的不同,例如:myprg.java 和 MyPrg.java,你在送交和更新時可能會碰到一些麻煩。
--------------------------------------------------------------------------------
實務 9. 指定忽略的檔案
在一個專案裡面,可能有些目錄裡面的某些檔案是你不希望加入檔案庫的,因此你在第一次匯入檔案庫之前,最好先把這些檔案搬移到別處,等到匯入檔案庫之後,在把它們搬回來,並且將這些檔案加入忽略清單。以 Web 應用程式為例,參考下列步驟:
先大致建構出網站的雛形,檔案目錄結構大致底定之後,才將檔案匯入檔案庫。
建立檔案庫,並且準備匯入檔案庫。有一些檔案可能是你不希望進行版本控管的,因為當其他小組成員更新這些檔案之後,可能會造成他的開發環境出問題,例如:無法編譯或執行程式等。不管是什麼原因,只要你有不想要放入檔案庫的檔案,就在匯入檔案庫之前,先把整個專案的檔案複製一份到一個暫存目錄下(c:\temp),然後把 c:/temp 中所有不想控管版本的檔案刪除掉,然後再匯入檔案庫。匯入完成後把 c:/temp 底下的檔案全部刪除。
取出專案。先把整個專案的檔案*搬移*到 c:/temp 底下,接著從檔案庫取出(check out)專案,假設取出至 d:/myprj 目錄下。
把 c:/temp 底下的所有檔案複製到 d:/myprj,注意所有已經存在的檔案都不要覆蓋掉,亦即只複製新的檔案過去。這些新的檔案並未加入版本控制,你可以把它們加入忽略清單(ignore list)裡面,以後這些檔案就不會被存入檔案庫了。
--------------------------------------------------------------------------------
Q & A
--------------------------------------------------------------------------------
問題:
使用 client 工具存取檔案庫時(例如:browse, commit, update),client 工具好像當掉了。
原因:
可能是因為 client 端在某次 commit 時異常中止動作,導致 server 端的 Subversion 資料庫鎖定無法釋放,一直等待 client 結束這次的 commit,因此其他的 clients 也必須等待,看起來就像當掉一樣。
解答:
使用 svnadmin 工具來復原資料庫,例如:
c:/>svnadmin recover d:/svn/MyRepos
--------------------------------------------------------------------------------
問題:
每次 Eclipse/WSAD 建置專案以後,類別輸出路徑底下的檔案版本就會跟 JavaSource 的檔案相互混淆?
原因:
Eclipse/WSAD 在建置專案時,會先把建置路徑完全清空,然後把 JavaSource 裡面的所有檔案目錄複製一份到 建置路徑(類別輸出路徑)下,但只有 .java 檔但不會複製過去,而是會將他們編譯成 .class 檔。這樣會導致 JavaSource 底下的 .svn 目錄都被複製到建置路徑下,例如:WEB-INF\classes\.svn,導致類別輸出路徑下的 .svn 目錄被蓋掉,因而使得 classes 目錄和 JavaSource 目錄混淆,發生相互影響的情形。
解答:
解決方法是修改 Eclipse/WSAD 的編譯器設定,把 ".svn/" 加入「已過濾的資源(Filtered Resource)」。參考下面的 WSAD 設定圖:
這樣設定還不夠,因為 Eclipse/WSAD 預設在建置專案時會先清空建置路徑(類別輸出路徑),使得建置路徑下的 .svn 目錄被清掉,因此,類別輸出路徑應該不要加入版本控制,做法是使用 svn:ignore 把建置路徑排除。
但是有些情況你可能還是希望將建置路徑加入版本控制,例如:你希望每當有小組成員編譯好他的檔案時,立刻 check in 就能立刻對新的程式進行測試,而不用等到 daily build 或 weekly build 完成時。
所以,如果你想要將建置路徑加入版本控制,除了更改 Filtered Resource 選項,還要讓 Eclipse/WSAD 在建置專案時不清空資料夾,此選項為「進行完整建置時清除輸出資料夾」,在上面的圖中可以找到。可是這樣一來,以後建置路徑可能會留下一些垃圾檔案,每當你刪除 JavaSource 裡面的檔案被刪除時,要記得到建置路徑下刪除對應的 .class 檔。
網路資源
Subversion 在 WebSphere 的應用
http://www.juee.com.tw/bartender/svn-present/svn-wsad.htm
摘自:http://huanlin.dyndns.org/techshare/articles/2005031801/svn_practical.htm
一旦你使用了 Subversion 來管理版本,檔案庫就成為你開發時最重要的資產之一了,因此最好利用排程工具,定期將檔案庫備份,如果你的檔案庫都放在一個統一的目錄下,例如:d:/svn,就只要完整備份這個目錄就行了。
--------------------------------------------------------------------------------
實務 2. 盡量熟悉命令列工具
儘管你大部分時候都是使用視覺化工具(例如:TortoiseSVN)來執行版本控制的日常工作,熟悉命令列工具仍然非常有用,特別是當你要執行一些批次作業時。
--------------------------------------------------------------------------------
實務 3. 建立測試環境
有些團隊可能是用 nightly build 或 weekly build 的建置方式,然後對新建置的版本進行測試,這種方式可能是由專人負責建置,然後把新版的程式部署到測試機器上。
另一種可能的情況是,測試人員隨時都可以測試最新版的程式,也就是每當程式修改好,check in 到檔案庫之後,測試人員就要能測到最新版的程式。這種需求可以透過在測試機器上建立排程來達到,排程的工作是執行一個批次檔,而這個批次檔裡面就是些 Subversion 的 update 命令。例如:
REM 此批次檔用來更新測試機器的程式檔案
c:
cd\MyProject\BookWeb\BookWeb.war
svn update -N
cd Image
svn update
cd ..
cd Script
svn update
cd ..
cd Jsp
svn update
cd ..
cd WEB-INF\classes
svn update
cd ..\lib
svn update
cd ..
這種方式要注意一個問題,就是測試機器上的應用程式目錄裡面,每個目錄都會有一個隱藏的 .svn 目錄。如果要把測試機器上的檔案部署到用戶端,並且排除 .svn 目錄,就要使用 Subversion 的匯出(export)功能。
--------------------------------------------------------------------------------
實務 4. 只 check in 完成的檔案
程式還有編譯錯誤及警告時,不要 check in 到檔案庫。一方面是基於測試的理由(程式當然是可以運作才放上去測試),另一方面,是因為這樣做可能會對別人造成困擾,因為別的開發人員可能有將整個專案的程式碼取出,那麼每當他在本機上建置專案時,就會出現一堆編譯錯誤,包括他自己的程式和你的程式的錯誤。如果每個人都在程式還未能通過編譯時就 check in,那麼每次編譯專案產生的錯誤訊息將多到令人無法忍受。
--------------------------------------------------------------------------------
實務 5. 每次 check in 時,輸入摘要事項
每當我們要 check in 檔案時,Subversion 會要求我們輸入一段文字,用來簡單說明這次 check in 做了哪些改變。你可以把重要的備註事項寫進去,以後如果要回頭比對版本,可以幫助你更找到需要的版本。
--------------------------------------------------------------------------------
實務 6. 不要保留沒用的註解
以往沒有版本控制時,我們在修改程式時,常常會把一段程式碼註解掉,以便日後反悔時,可以恢復。但是這類註解掉的程式碼往往會一直留在那裡,直到程式改了好幾個版本,已經沒有利用價值以後,成為程式裡的一堆礙眼的垃圾。
有了版本控制以後,因為可以隨時回到任一個歷史版本,你可以放心的把不要的程式碼刪除,再配合實務 5,以後要恢復歷史版本就很容易了。
--------------------------------------------------------------------------------
實務 7. 不要留下多餘的檔案
以往沒有使用版本控制系統時,我們有時候會自己做一點版本管理,例如修改 Foo.java 之前,先把它複製成一個新的檔案,並且加上序號,例如:Foo_1.java,然後再修改 Foo.java。現在有了版本控制系統,可以不用這樣了,免得多了一堆垃圾檔案。
我曾看過一種情況,就是有人還是習慣用附加編號的方式自己備份舊版的檔案,而且跟新版的檔案放在同一個目錄下,另一方面,他又習慣把程式的檔名用序號來命名(懶得想個適切的檔名),結果備份的檔名和開發中的檔名都是用序號來命名,有一天某人要清理專案目錄中的垃圾時,就把所有帶序號的檔名都砍了,造成程式無法編譯或執行。還好我們有時光機器可以回到過去,要不然就麻煩了。
--------------------------------------------------------------------------------
實務 8. 檔名大小寫第一次就決定好
如果你的作業系統不區分檔名的大小寫,例如:Windows,你最好第一次就把檔案名稱的大小寫確定下來。否則如果日後要改檔名,而且新的檔名和舊的檔名只有大小寫的不同,例如:myprg.java 和 MyPrg.java,你在送交和更新時可能會碰到一些麻煩。
--------------------------------------------------------------------------------
實務 9. 指定忽略的檔案
在一個專案裡面,可能有些目錄裡面的某些檔案是你不希望加入檔案庫的,因此你在第一次匯入檔案庫之前,最好先把這些檔案搬移到別處,等到匯入檔案庫之後,在把它們搬回來,並且將這些檔案加入忽略清單。以 Web 應用程式為例,參考下列步驟:
先大致建構出網站的雛形,檔案目錄結構大致底定之後,才將檔案匯入檔案庫。
建立檔案庫,並且準備匯入檔案庫。有一些檔案可能是你不希望進行版本控管的,因為當其他小組成員更新這些檔案之後,可能會造成他的開發環境出問題,例如:無法編譯或執行程式等。不管是什麼原因,只要你有不想要放入檔案庫的檔案,就在匯入檔案庫之前,先把整個專案的檔案複製一份到一個暫存目錄下(c:\temp),然後把 c:/temp 中所有不想控管版本的檔案刪除掉,然後再匯入檔案庫。匯入完成後把 c:/temp 底下的檔案全部刪除。
取出專案。先把整個專案的檔案*搬移*到 c:/temp 底下,接著從檔案庫取出(check out)專案,假設取出至 d:/myprj 目錄下。
把 c:/temp 底下的所有檔案複製到 d:/myprj,注意所有已經存在的檔案都不要覆蓋掉,亦即只複製新的檔案過去。這些新的檔案並未加入版本控制,你可以把它們加入忽略清單(ignore list)裡面,以後這些檔案就不會被存入檔案庫了。
--------------------------------------------------------------------------------
Q & A
--------------------------------------------------------------------------------
問題:
使用 client 工具存取檔案庫時(例如:browse, commit, update),client 工具好像當掉了。
原因:
可能是因為 client 端在某次 commit 時異常中止動作,導致 server 端的 Subversion 資料庫鎖定無法釋放,一直等待 client 結束這次的 commit,因此其他的 clients 也必須等待,看起來就像當掉一樣。
解答:
使用 svnadmin 工具來復原資料庫,例如:
c:/>svnadmin recover d:/svn/MyRepos
--------------------------------------------------------------------------------
問題:
每次 Eclipse/WSAD 建置專案以後,類別輸出路徑底下的檔案版本就會跟 JavaSource 的檔案相互混淆?
原因:
Eclipse/WSAD 在建置專案時,會先把建置路徑完全清空,然後把 JavaSource 裡面的所有檔案目錄複製一份到 建置路徑(類別輸出路徑)下,但只有 .java 檔但不會複製過去,而是會將他們編譯成 .class 檔。這樣會導致 JavaSource 底下的 .svn 目錄都被複製到建置路徑下,例如:WEB-INF\classes\.svn,導致類別輸出路徑下的 .svn 目錄被蓋掉,因而使得 classes 目錄和 JavaSource 目錄混淆,發生相互影響的情形。
解答:
解決方法是修改 Eclipse/WSAD 的編譯器設定,把 ".svn/" 加入「已過濾的資源(Filtered Resource)」。參考下面的 WSAD 設定圖:
這樣設定還不夠,因為 Eclipse/WSAD 預設在建置專案時會先清空建置路徑(類別輸出路徑),使得建置路徑下的 .svn 目錄被清掉,因此,類別輸出路徑應該不要加入版本控制,做法是使用 svn:ignore 把建置路徑排除。
但是有些情況你可能還是希望將建置路徑加入版本控制,例如:你希望每當有小組成員編譯好他的檔案時,立刻 check in 就能立刻對新的程式進行測試,而不用等到 daily build 或 weekly build 完成時。
所以,如果你想要將建置路徑加入版本控制,除了更改 Filtered Resource 選項,還要讓 Eclipse/WSAD 在建置專案時不清空資料夾,此選項為「進行完整建置時清除輸出資料夾」,在上面的圖中可以找到。可是這樣一來,以後建置路徑可能會留下一些垃圾檔案,每當你刪除 JavaSource 裡面的檔案被刪除時,要記得到建置路徑下刪除對應的 .class 檔。
網路資源
Subversion 在 WebSphere 的應用
http://www.juee.com.tw/bartender/svn-present/svn-wsad.htm
摘自:http://huanlin.dyndns.org/techshare/articles/2005031801/svn_practical.htm
訂閱:
文章 (Atom)