Subversion With Mac OS X Tutorial

Subversion is a version control system that allows you to work with other people on a project and switch back easily to every version ever made. It can be used for all kinds of projects like application source code, web sites, even images or just simple text documents. Once you have it all set up and followed all the steps described below, it is easy to handle and a very useful thing – not just for computer geeks.

About This Tuturial
This tutorial explains the basics from installing subversion and getting started to working with other people on the same project. It is written primarly for Mac OS X users, but since Subversion itself works the same on all platforms, most of this tutorial should apply to Linux or Windows users, too.
The Concept of Subversion
Subversion works by setting up a central repository on a server or local computer that every user connects to and downloads a personal working copy from. When changes are made to the working copy, they can be uploaded to the repository. If these changes conflict with changes other people may have uploaded since the last time you updated your working copy, subversion tries to merge these files and solve the conflicts.

Downloading and Installing Subversion
I recommend downloading the Subversion Mac OS X package from Collabnet

Download and run the installer. Note that Subversion itself doesn't feature a graphical user interface, so you won't find any new files in your application directory after installation. Instead it installs some command line commands into the directory /opt/subversion/bin* on your hard drive. *Note: For other Subversion packages this path is usually /usr/local/bin.

To be able to call the Subversion commands from every directory, you must add it to your path. If you don't know what that means, don't worry. Just follow the instructions.

Open the Terminal application. It can be found in the /Applications/Utilities folder. Whenever you see below a line starting with a dollar sign, you should type the text after the dollar sign in your terminal and hit return.

Start by creating a new text file called '.bash_profile', i.e. with the command line text editor pico:

$ pico .bash_profile
Add the following line to the text file:

export PATH=/opt/subversion/bin/:$PATH
Now hit Control-X, then confirm saving the file with 'y', followed by return.

You have just added Subversions's location to your path. Let Terminal read this file to know the path has changed (there's an empty space between the dots):

$ . .bash_profile
Creating a Sample Subversion Project
First we will need to set up a Subversion repository on our local computer. That is the place to store all versions of our project. Now create your repository like this:

$ svnadmin create SVNrep
This will create a repository named 'SVNrep' in your your home directory, although svnadmin won't give you any feedback. If you don't trust me on this, you can check the existence of this folder by typing 'ls' in the terminal or looking for it in the Finder.

Next we create our sample project. Create a new folder and an empty file named 'test.txt' inside this folder:

$ mkdir test
$ touch test/test.txt
Let's import this project into the repository. Type in your terminal, by replacing 'sara' with your own user name:

$ svn import test file:///Users/sara/SVNrep/test -m "Initial import"
This will output:

Adding test.txt
Committed revision 1.
We have just imported the folder 'test' into the repository 'SVNrep'. Each version in the repository is called a "revision" and is identified by a unique number. Always provide a short message ('-m') of the changes you made to the repository like we just did!

Retrieving Files From Subversion
Now we get a copy to work on from the repository. This process is called "check out":

$ svn checkout file:///Users/your_user_name/SVNrep/test test-copy
The output will show all files added ('A') to our working copy:

A test-copy/test.txt
Checked out revision 1.
Change into the working copy directory by typing:

$ cd test-copy
Next check the content of our working copy in the terminal:

$ ls -a1
This will output the directory including hidden files:

.
..
.svn
test.txt
Note the hidden directory '.svn'. This holds some subversion info like the name of the repository, so you don't have to type that in the future. If you would like a copy of your repository without this hidden directory in every folder, you have to export a copy:

$ svn export file:///Users/your_user_name/SVNrep/test test-copy
This copy is now safe to deploy on the web. It is not a working copy though, so you can't commit changes back to the repository from this folder.

Time For Changes
It is time to make some changes to our file and save it back to the repository. Open 'test.txt' from the working copy with your favourite text editor and type "Hello world" or whatever you are up to, then save the file.

You can then query Subversion to find out the differences between the repository and your copy:

$ svn status
This will state that our file has been modified ('M'):

M test.txt
Now we want to update the repository with the changes we made. This process is called "committing":

$ svn commit -m "Added some text"
This will output:

Sending test.txt
Transmitting file data .
Committed revision 2.
Dealing With All These Versions
Let's assume, that someone else working on your project made changes to the repository. You will want to update your local working copy to incorporate the changes:

$ svn update
Because in our example nobody else made changes to the repository, this will do nothing and output:

At revision 2.
To list all revisions in the repository, type:

$ svn log
This will output a list of all revisions with it's messages:

------------------------------------------------------------------------
r2 | sara | 2006-10-08 16:41:46 +0200 (Sun, 08 Oct 2006) | 1 line
Added some text
------------------------------------------------------------------------
r1 | sara | 2006-10-08 16:10:36 +0200 (Sun, 08 Oct 2006) | 1 line
Initial import
------------------------------------------------------------------------
If you would like to see the exact differing lines to a specific revision, i.e. revision 1, just type:

$ svn diff -r 1
The output states that the line "Hello world" has been added ("+"):

Index: test.txt ===================================================================
--- test.txt (revision 1)
+++ test.txt (working copy)
@@ -0,0 +1 @@
+Hello world
Maybe you would then rather like to switch back to an older revision:

$ svn update -r 1
This will update ('U') your copy back to revision 1 and output:

U test.txt
Updated to revision 1.
Note that all commands are used on the whole current working directory. You could also provide a single filename for each of these commands, i.e. 'svn update test.txt'.

Renaming, Adding And Deleting Files From The Repository
Sometimes you may add new files to your working copy.

$ touch test2.txt
They will not be included in the repository though, unless you manually add them to the repository:

$ svn add test2.txt
$ svn commit -m "added new file"
If you later would like to remove a file from the repository, type likewise:

$ svn delete test2.txt
$ svn commit -m "deleted file"
Note that you should never delete or rename files from your working copy without Subversion knowing. You can modify inside your files as much as you like. But if you just rename files or move them to another folder, Subversion will loose track of them. Always use 'svn' commands for those operations.

This is how you move a file accordingly:

$ svn move oldfilename newfilename
$ svn commit -m "moved file"
All of these commands will not only affect the repository, but your working copy as well. So you should never have to delete or rename a file with your Finder.

If you are working alone on a project, this is it! Well, basicly. The next chapter will explain dealing with multiple users.

Working With Other People
To act as if someone else was working on your project, you could now check out a second working copy named i.e. 'test-copy2' into your home directory and make some more changes to it. Then commit it to the repository following the steps from above.

Now think of a possible conflict: two people have downloaded their working copy and started working on the same file. When Sara commits her files before Michael does, Michael will get an error message when committing because his copy is not up to date any more:

$ svn commit -m "Some change by Michael"
Sending test.txt
svn: Commit failed (details follow):
svn: Out of date: '/test/test.txt' in transaction '3-1'
Michael will then first have to update his working copy by typing 'svn update'. This will merge Sara's earlier changes into Michael's working copy, line by line.

Michael can now commit the merged copy to the repository. In some rare cases however, there my be a conflict that Subversion cannot solve itself. It will then create three files in Michael's working copy:

test.txt.mine
test.txt.r2
test.txt.r3
Michael now has to manually put the pieces together in the file 'test.txt', deciding which changes to keep. Only when this is made and the three extra files are deleted, Subversion will allow Michael to commit his files.

Now go play around with it to get used to it. Of course there is more to Subversion. You could type "svn help" in the terminal to list all commands or read the freely available SVNbook at http://svnbook.red-bean.com

Graphical User Interfaces
Many people don't like working with the terminal. They find it complicated to remember the text commands, as opposed to clicking on buttons in applications. There is a couple of free or commercial apps available on the internet, that provide a graphical user interface for Subversion commands. I think it's best practice to learn Subversion from the terminal first, before you use a graphical client, to understand the way subversion works better.

A nice and free GUI for Mac OS X is svnX. To manage your working copies from the same application that you write your code with, the text editor TextMate is a good choice. TextMate includes a Subversion bundle that allows you to easily invoke most Subversion commands from the menu. Only once for setting up the repository and checking out the first working copy, you will have to use the terminal. After that, just press Shift-Control-A to open the Subversion bundle menu.

摘自：http://www.rubyrobot.org/tutorial/subversion-with-mac-os-x

Use another user to svn update

svn switch --relocate svn://oldname@anonsvn.opensource.apple.com/svn/webkit/trunk \
http://newname@svn.webkit.org/repository/webkit/trunk

.htaccess / httpd.conf deny access to .svn directories

    Order allow,deny
    Deny from all

寄送 subversion repository 的更新通知

subversion 提供了一個很方便的 hook 功能，可以為對 repository 進行的動作設定相關的動作。詳細的作法請見 svnbook 第 5 章的 Hook Scripts 一節。這裡簡單筆記一下如何用 svn hook 作 repository 的 email 更新通知。



在 subversion repository 目錄裡面有 conf, dav, db, hooks, locks 等目錄。其中 hooks 目錄就是用來存放 hooks 的地方。總共有 5 種 hook：

start-commit: 在 commit 開始之前執行，常用來檢查使用者是否有權執行動作。
pre-commit: 在 transaction 完成而未真正 commit 之前執行，常用來檢查 commit 動作的有效性。可以在這個地方對 commit 時的 log 訊息進行要求。
post-commit: 在 transaction 完成而 commit 結束，建立了新的 revision 之後執行，常用來寄送 e-mail 通知訊息。
pre-revprop-change: subversion 的 revision property 並不會存入 repository，這個 hook 可以在 revision property 變更之前作一些處理，譬如把更新的資訊存到外部的紀錄檔裡面。
post-revprop-change: 用途與 pre-revprop-change 類似，但會在 revision property 變更之後執行。
看起來 hook 在 post-commit 上面最為合適。subversion 提供了 Perl 與 Python 的 email 寄送程式 commit-email.pl 與 mailer.py 。經我測試， commit-email.pl 在寄 email 的時候沒辦法正確處理 non-ascii log message，但 mailer.py 可以寄送 utf8 log message。此外， commit-email.pl 只接受命令列參數，但 mailer.py 則可以用設定檔進行比較多的組態。

Debian 把 subversion 提供的一些補充工具 (像 commit-email.pl 和 mailer.py) 包在 subversion-tools 裡面，請記得安裝。

首先要把 post-commit 打開，假設 $repo 是 repository 所在的目錄，那麼要先建立 $repo/hooks/post-commit 。該目錄下預設就有一個模板檔：

$ cd $repo/hooks
$ cp post-commit.tmpl post-commit
$ chmod a+x post-commit
這是一個 shell script。它不必然要是 shell script，只要是可執行檔即可 (可以用 Perl, Python 或 C 來寫)。原本它使用 commit-email.pl ，我們來把它改成 mailer.py ：

#!/bin/sh
REPOS="$1"
REV="$2"
/usr/lib/subversion/hook-scripts/mailer/mailer.py commit $REPOS $REV
mailer.py 要有三個參數，第一個參數是 commit 與 propchange 兩者之一，指定用於 *-commit 或 *prop-change 時的 email 寄送。不過僅是這樣還不能運作，我們得在 $repo/conf 裡放好組態檔 mailer.conf 才行：

cp /usr/lib/subversion/hook-scripts/mailer/mailer.conf.example $repo/conf/mailer.conf
Note

直接執行 /usr/lib/subversion/hook-scripts/mailer/mailer.py 不給參數，就會秀出參數的說明。
我們必須設定組態檔裡 [general] 區塊裡的 mail_command 及 smtp_hostname (一般使用預設值即可)，以及 [defaults] 區塊裡的 to_addr 。 to_addr 就是 email 要通知的地址，可以設很多個，其間用空白分隔。

[defaults] 區塊裡還有

commit_subject_prefix 可以用來設定 commit 時 email Subject: 的前飾詞
propchange_subject_prefix 設定 revision property 改變時的 email Subject: 前飾詞
範例：

[general]
diff = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s %(from)s %(to)s
mail_command = /usr/sbin/sendmail
smtp_hostname = localhost
[defaults]
commit_subject_prefix = [repocommit]
propchange_subject_prefix = [repopropchange]
from_addr =
to_addr = my@email.address
reply_to =
generate_diffs = add copy modify
suppress_deletes = yes
如果不指定 from_addr 的話，From: 就會填入 committer 的使用者名稱。

摘自:http://blog.seety.org/everydaywork/2005/7/13/378/

SVN auto send password with shell script

expect -c 'spawn svn up /Users/williamchang/workspace_php/urstyle/urcosme/." ; expect password; send "yourpassword\n"; interact'

解決 This client is too old to work with working copy 的問題

前陣子為了測試一個 TortoiseSVN 的問題，因此改安裝了 Nightly Builds 的版本，當確認問題順利解決後也就沒換到正式的版本了，所以我從今年 9 月份一直用到現在，但今天我將這個版本移除，改安裝目前最新的 TortoiseSVN-1.5.5.14361 版本，卻發生了 "This client is too old to work with working copy" 的錯誤訊息。越想越怪，不是應該都是 1.5 版的 Subversion 嗎？為什麼會有這種匪夷所思的錯誤呢？

查了一個小時後才發現，原來我之前安裝的 Nightly Builds 抓到了 svn-1.6.0 的版本了，所以我這一個半月來所有用過的工作目錄(Working Copy)都被我升級到 1.6 的版本了，所以導致我今天重新安裝 TortoiseSVN-1.5.5.14361 後，許多專案都無法經由 TortoiseSVN 存取！

我透過錯誤訊息上面的連結，找到了解決方法。只要下載一支用 Python 寫的 Script ( change-svn-wc-format.py ) 並對我無法存取的工作目錄執行以下指令即可：

c:\change-svn-wc-format.py C:\Projects\TEST\TESTWC 1.5

其中第一個參數是「工作目錄」的路徑。第二個參數是要改變工作目錄的版本編號，因為我的工作目錄之前被升級到 1.6 了，所以我必須指定 1.5 把版本降下來！

而我轉換了十幾個專案，其中有一個專案轉換會失敗，我多使用了 --force 參數解決此問題，例如：

c:\change-svn-wc-format.py C:\Projects\TEST\TESTWC 1.5 --force

若執行成功會顯示以下結果：

Converted WC at 'C:\Projects\TEST\TESTWC' into format 9 for Subversion 1.5

以下是目前 subversion 的版本與格式編號的對應關係：

* 1.4 ==> 8
* 1.5 ==> 9
* 1.6 ==> 10

你可以從任意一個 _svn 或 .svn 目錄下找倒一個名叫 format 的檔案，裡面會有你專案 Working Copy 目錄的版本。只不過直接改這個檔案的內容是沒用的，還是要透過 change-svn-wc-format.py 工具幫你修改工作目錄才行。

我還發現一點，透過 change-svn-wc-format.py 工具修改過的工作目錄，有些 format 檔案會變成 9，但有些不會，我不太確定為什麼會這樣，不過反正 TortoiseSVN 1.5 都可以正常操作就是了。

最後，我補充一個好用的 DOS 指令，可以一次針對目前目錄下所有的 Working Copy 進行轉換動作：

c:\Projects>for /D %d IN (*) DO d:\change-svn-wc-format.py "%d" 1.5

摘自：http://blog.miniasp.com/post/2008/11/Solve-This-client-is-too-old-to-work-with-working-copy-problem.aspx

補充：XP請至http://www.python.org/download/releases/2.6.2/下載python2.6.2，下載ptyhon3.X會有問題喔~

在TortoiseSVN上使用svn+ssh遇到的問題

在TortoiseSVN上使用svn+ssh遇到的問題
關鍵字: svn tortoisesvn ssh svn+ssh 密碼
使用TortoiseSVN連svn+ssh的位址遇到的問題

在TortoiseSVN裡使用
svn+ssh://myuser@MyConnection/usr/local/repos

後提示要輸入密碼。雖然最終可以成功checkout代碼，但TortoiseSVN不斷的要求我輸入密碼。

解決方法：
settings -> Network -> SSH Client -> 修改用戶端為 TortoiseSVN_HOME\bin\TortoisePlink.exe 並加參數 -pw
比我的是
D:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -pw mypassword

如果在url裡沒有 myusername@ 那麼這裡還要指定 -l myusername

摘自:http://wangcheng.javaeye.com/blog/202137

PUTTY、 TortoiseSVN 不用輸入密碼

由於使用 TortoiseSVN 做文件版本的控管，但取出及寫入時，每次都要詢問密碼，而且常連問好幾次。它又無暫存的機制來簡化輸入密碼的功能，最後找到了它可以採用 ssh 的公、私鑰的方法來簡化登入的問題。

在伺服器中 ，會產生私鑰及公鑰兩個檔案

#ssh-keygen -t rsa

/home/user/.ssh/id_rsa
/home/user/.ssh/id_rsa.pub

把公鑰放入 authorized_keys
#cat id_rsa.pub >> authorized_keys

為了安全性，權限設為 600
#chmod 600 authorized_keys

在 windows client 端

取得 puttygen.exe 軟體，下載伺服器中的 id_rsa 。
這是 PUTTY 和 openssh 編碼方式不同，需要使用 puttygen.exe 做轉換成 putty 可以接受的格式。
Conversions → Import Key ，匯入 id_rsa 檔。
(在這兒可以輸入密碼來對私鑰做進一步的保護，但對 TortoiseSVN 還是會出現重複要求碼的情形，所以在這不再設密碼。)
按下 Save Private Key ，存成 C:\user.ppk

PUTTY 使用時，SSH --> AUTH 指定私鑰的檔案 (C:\user.ppk)
再使用 PUTTY 登入時就可以不使用密碼了。

TortoiseSVN -> 設定-->網路 --> ssh 用戶端
C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -i C:\user.ppk
就無需再輸入密碼。

如果 SSH port 改變，那麼這部份需要做改變，例(1234 port)：
C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -P 1234 -i C:\user.ppk

注意：私鑰檔一定要保存好，不可被取得，不然就毁了！

參考資料：
http://forum.icst.org.tw/phpBB2/viewtopic.php?p=23185&sid=53abacb0f55408629b5170032370336c&PHPSESSID=56201bb80a7f4851d00eec9bc2d442c3

（繼續）

---
http://forum.icst.org.tw/phpBB2/viewtopic.php?p=31000

1.修改 /etc/ssh/sshd_config
#在 sshd_config 裡,找到與下列相符的選項,就將選項前的 # 號拿掉:
Protocol 2
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin yes
#找到 ChallengeResponseAuthentication yes 的選項,改成 no ,如下:
#(選項解釋:密碼登入選項,一定要改成 no,這樣子沒有擁有私鑰的人就會無法登入了)
# Change to no to disable s/key passwords
#修改成 no 來停用 s/key 密碼
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
還有把 PasswordAuthentication yes
改成 PasswordAuthentication no
#以下為非必要選項
SyslogFacility AUTHPRIV(或 SyslogFacility AUTH)
LogLevel INFO

接下來就存檔離開
重新啟動 sshd 服務.
#service sshd restart

2.在 Server 端,使用 ssh-keygen 來建立 DSA Private Key 和 Public Key.
先檢查 /root 下有沒有 .ssh 的資料夾,如果有就略過建立資料夾的步驟,
在 /root 下建立資料夾 .ssh,
#mkdir .ssh
#cd .ssh
#ssh-keygen -b 2048 -t dsa
然後,輸入 Private Key(私鑰)檔名:id_dsa,和 Public Key(公鑰)檔名:id_dsa.pub
這個時候會問你 key passphrase,
(可以自由選擇輸入與否,即使現在不輸入也沒關係,
後面再用 puttygen.exe 轉換格式時再輸入,也是可以的,
但是不可為了省卻輸入密碼,而只用 KEY 就登入 LINUX 系統,
此舉很危險,萬一 Key 檔案被有心人士偷取,就糟糕了.>" authorized_keys

3.因為 Openssh 的私鑰格式和 putty 使用的格式截然不同,
所以需要由 puttygen.exe 轉換格式後才能使用,不然可能會有兩種錯誤的情況:
--------------------------------------------------------------
可能出現的幾種問題:
(a)、Server refused our key
公鑰和私鑰不匹配，或者沒有 authorized_keys 文件
(b)、Unable to use key file "id_dsa.ppk" (SSH2 private key)
私鑰檔案的格式不正確
--------------------------------------------------------------
3.1把 server 上的私鑰:id_dsa 拷貝到 PC 上
將 id_dsa 的內容顯示在螢幕上,再複製下來.
#cat id_dsa
把複製的內容貼到記事本裡存成 id_dsa_by_ssh-keygen.ppk
再來就是開啟用 puttygen.exe → Conversions → Import Key
匯入後,在 Key passphrase 和 Confirm passphrase 輸入保護私鑰的密碼後,
(不想打密碼的人,就保留成空白也可以,不過萬一私鑰掉了被撿到,那就慘了>" authorized_keys
但是要確認在 /home/[users]/.ssh/ 路徑和檔名有沒有錯誤。
[users]→表示為 user 的帳號名稱。

2把 server 上的私鑰:id_dsa 拷貝到 PC 上
將 id_dsa 的內容顯示在螢幕上,再複製下來.
#cat id_dsa
把複製的內容貼到記事本裡存成 id_dsa_by_ssh-keygen.ppk
(檔名命名方法沒有一定,但是為不讓自己搞不清楚,這樣子做最好)
再來就是開啟用 puttygen.exe → Conversions → Import Key
(匯入時,因為我們在用 ssh-keygen 產生公/私鑰時,就有用密碼了,所以在你使用 puttygen.exe,
做匯入的動作時,自然會要求你輸入密碼了)
匯入後,在 Key passphrase 和 Confirm passphrase 輸入保護私鑰的密碼後,
(不想打密碼的人,就保留成空白也可以,不過萬一私鑰掉了被撿到,那就慘了"),
然後,再從 File → Save Private Key 把私鑰另存新檔即可使用了。

[color=red]3.強烈建議:私鑰(Private Key)一定要用 Key Passphrase 來保護,
密碼(至少 8 位數以上,每三個月更換一次公/私鑰)千萬不要跟 root 的密碼一樣.

4.因為我是用 root 來替 splin 這個 user 建立公/私鑰,
所以我要把檔案權限和屬性稍微修改一下。
#chown -R splin.splin /home/splin/.ssh/
#chmod -R 755 /home/splin/.ssh/

5.Pietty/Putty 使用方法:
啟動 Pietty/Putty ,從 SSH → Auth 去指定私鑰的檔案路徑即可。


摘自:http://w3.sy3es.tnc.edu.tw/blogs/index.php/2006/03/08/puttya_tortoisesvn_ac_c_uefca_yam_ccf?blog=2

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

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

TortoiseSVN教學

http://www.dev.idv.tw/mediawiki/index.php/TortoseSVN%E4%BD%BF%E7%94%A8%E7%B0%A1%E4%BB%8B

刪除subversion的帳號&密碼

C:\Documents and Settings\user\Application Data\Subversion\auth

把svn.simple,svn.ssl.server,svn.username刪除即可

Subversion - Cleanup Failed To Process The Following Paths

SOLUTION I
1) Try and determine what rev your Working Copy is checked out at -
file->properties->subversion should tell you this, but the picture may
be less clear if you have mixed revisions.

2) Check out a new Working Copy at the revision you've just determined

3) Create a patch from your broken Working Copy

4) Apply the patch to your new Working Copy

5) Continue using the new one. Delete the broken copy when you're
confident you no longer need it.

TortoiseSVN: 解決TSVNCache佔用CPU過高的設定

竟然被中文介面誤導了這麼久！如果你偶爾在工作管理員裡發覺TSVNCache.exe突 然耗用許多CPU資源(有時會超過50%)，那要趕緊去檢查TortoiseSVN的 設定。原來是這個常駐的Process會定時去掃描受Subversion控 管的檔案是否被修改了，掃描到後，這些被修改的檔案、與其所屬的子目錄、目錄等的覆蓋圖示都一併更新，而就是這個動作不僅佔用約10-50 MB記憶體，也會瞬間衝出超過CPU 50%負載。

圖示覆蓋與狀態欄更新設定
打開TortoiseSVN的 【設定視窗(Settings)→視覺樣式(Look and Feel)→圖示覆蓋(Icon Overlays)】，右邊第一個Radio Group名稱「圖示覆蓋/狀態列」的英文是「Icon Overlays/Status Columns」，其中的Status Columns應譯成狀 態欄才對，它指的是在檔案總管裡把顯示模式切換成詳細資料時， 標題欄位裡的Subversion欄位是否要同步更新狀態。如果你只會在檔案總管裡操作Subversion狀態的話，應該把「僅在檔案總管中顯示圖示覆 蓋」打勾，以免除另存新檔、開啟檔案等對話窗也更新圖示狀態。但我有時會在Total Commander裡操作Subversion，因此就不能勾選。

狀態快取設定
右邊第二個Radio Group名稱譯成「狀態列」，讓人誤解成以為是顯示訊息的狀態列設 定，但其實英文是Status Cache－狀態快取設 定，指的是資料夾與檔案圖示的SVN小圖示的覆蓋狀態的處理模式。Status Cache有3個選項：

Default
預設的快取設定，使用TSVNCache.exe 來定時掃描檔案系統，找到要變動的檔案後發出更新圖示的通知給作業系統

Shell
在Shell extension裡，只針對目前所在資料夾做圖示異動更新；只佔用1MB記憶體，但因只快取一個資料夾，當Working copy內容較多時會花較多時間才能更新完畢

None
不做任何圖示覆蓋快取，因此圖示更新速度較慢

我特別做了測試把狀態改用Shell，重新開機後工作管理員裡就找不到TSVNCache.exe 了，用檔案總管檢視Working copy資料夾時，圖示覆蓋以較緩慢的速度顯示出來。

磁碟機類型
磁碟機類型是指定讀取Subversion檔案狀態的對象，建議選硬碟，以免別的媒體較慢的讀取速度造成TortoiseSVN效 能低落。

在Subversion Forum這篇討論裡也有如下建議：

把A:\*、C:\*、D:\*到Z:\*都加到除外路徑裡，表 示每個磁碟都不做異動掃描
再把工作中的Working copy加入包含路徑，如c:\NewProject\*、 d:\NewWD
再試用觀察一陣子再來確認應該用那樣的設定較好。

摘自:http://blog.roodo.com/emisjerry/archives/3979261.html

【轉貼】Subversion權限設定之詳細解說

1   背景假設

廈門央瞬公司是一家電子元器件設備供應商，其中有個ARM部門，專門負責ARM晶片的方案設計、銷售，並在北京、上海各設立了一個辦事處。對於工作日志，原先採用郵件方式發給經理，但是這種方式有個缺點，那就是不具備連續性，要看以前的日誌必須一封一封郵件去查看，很麻煩。於是就想到利用 Subversion， 讓員工在自己電腦上編輯日誌，然後利用svn傳送回來，既方便員工自己編寫日誌，又方便對日誌的歸檔處理，而且提交日誌的時候只需要執行一下 svn update 即可，比發送郵件還要簡單的多。

 

• svn伺服器相關資訊




• 伺服器地址： 192.168.0.1


• 伺服器OS： MS Windows 2000 Server Edition 中文版


• 代碼庫本地目錄： D:\svn\arm




• arm部門文檔的目錄結構如下:


• arm                 部門名稱


• ├─diary           工作日志目錄


• │  ├─headquarters    總部工作日志目錄


• │  ├─beijing         北京辦日誌目錄


• │  └─shanghai        上海辦日誌目錄


• ├─ref             公司公共檔參考目錄


• └─temp            暫存檔案目錄


• 人員情況




• morson，公司總經理，其實他不必親自看任何東西，就連部門經理們的每週總結都不一定看。但是為了表示對他的尊敬，以及滿足一下他的權力欲，還是給他開放了“閱讀所有文檔”的許可權

• michael，arm事業部的部門經理，沒事的時候喜歡弄點兒新技術，用svn來管理日誌，就是他相處來的主意


• scofield，北京辦人員，老員工，為人油滑難管


• lincon，上海辦人員，老員工，大老實人一個


• linda，總部協調員、秘書，文筆不錯，長得也不錯


• rory，單片機技術員，技術支援




• 存取權限需求分析




• 允許總經理讀取所有檔


• 除部門經理外，所有其他人員，均只能看到本辦事處人員工作日志


• 不允許匿名訪問


• ref目錄只允許經理和秘書寫，對其他人唯讀


• temp目錄人人都可以寫

2   建立代碼庫

在伺服器 D:\svn 目錄下，建立 arm 代碼庫，命令如下:

D:\svn>svnadmin create arm

在客戶機 F:\temp 目錄下，建立好上述目錄結構

用命令 F:\temp>svnimportarmsvn://192.168.0.1/arm 導入結構

【注意點：關於導入時候的細微差別】

 

3   編輯代碼庫基礎設定檔

編輯代碼庫 arm\conf\svnserve.conf 文件，如下:

[general]

password-db = passwd.conf

anon-access = none

auth-access = write

authz-db = authz.conf

 

4   管理用戶帳號

新建代碼庫 arm\conf\passwd.conf 文件，如下:

[users]

morson = ShowMeTheMoney

michael = mysecretpassword

scofield = hellolittilekiller

lincon = asyouknows111

rory = 8809117

linda = IlikeWorldCup2006

 

5   建立目錄存取權限控制檔

新建代碼庫 arm\conf\authz.conf 檔，內容如下:

[groups]

g_vip = morson

g_manager = michael

g_beijing = scofield

g_shanghai = lincon

g_headquarters = rory, linda

g_docs = linda

[arm:/]

@g_manager = rw

* = r

[arm:/diary/headquarters]

@g_manager = rw

@g_headquarters = rw

@g_vip = r

* =

[arm:/diary/beijing]

@g_manager = rw

@g_beijing = rw

@g_vip = r

* =

[arm:/diary/shanghai]

@g_manager = rw

@g_shanghai = rw

@g_vip = r

* =

[arm:/ref]

@g_manager = rw

@g_docs = rw

* = r

[arm:/temp]

* = rw

 

6   測試

在伺服器上，打開一個 DOS Prompt 視窗，輸入如下指令:

svn co svn://127.0.0.1/arm --no-auth-cache --username rory --password 8809117

我們應該得到如下目錄結構:

arm

├─diary

│  └─headquarters

├─ref

└─temp

然後修改ref目錄下任意檔並提交，伺服器將會報錯“Access deni”

 

深入

本章將詳細介紹前一章所涉及的兩個設定檔， svnserve.conf 和 authz.conf，通過對配置逐行的描述，來闡明其中的一些細節含義。

這裡首先要注意一點，任何設定檔的有效配置行，都不允許存在前置空格，否則程式會無法識別。也就是說，如果你直接從本文的純文字格式中拷貝了相關的配置行過去，需要手動將前置的4個空格全部刪除。當然了，如果你覺得一下子要刪除好多行的同樣數目的前置空格是一件苦差使，那麼也許 UltraEdit 的“Column Mode”編輯模式，可以給你很大幫助呢。

 

1   svnserve.conf

arm\conf\svnserve.conf 文件，是 svnserve.exe 這個伺服器進程的設定檔，我們逐行解釋如下。

首先，我們告訴 svnserve.exe，用戶名與密碼放在 passwd.conf 文件下。當然，你可以改成任意的有效檔案名，比如默認的就是 passwd:

password-db = passwd.conf

接下來這兩行的意思，是說只允許經過驗證的用戶，方可存取碼庫。 那麼哪些是“經過驗證的”用戶呢？噢，當然，就是前面說那些在 passwd.conf 檔裡面持有用戶名密碼的傢伙。這兩行的等號後面，目前只允許 read write none 三種值，你如果想實現一些特殊的值，比如說“read-once”之類的，建議你自己動手改原始程式碼，反正它也是自由軟體:

anon-access = none

auth-access = write

接下來就是最關鍵的一句呢，它告訴 svnserve.exe，專案目錄存取權限的相關配置是放在 authz.conf 文件裡:

authz-db = authz.conf

當然，svn 1.3.2 引入本功能的時候，系統預設使用 authz 而不是 authz.conf 作為設定檔。不過由於鄙人是處女座的，有著強烈的完美主義情結，看著 svnserve.conf 有尾碼而 passwd 和 authz 沒有就是不爽，硬是要改了。

 

2   authz.conf 之用戶分組

arm\conf\authz.conf 檔的配置段，可以分為兩類，``[group]`` 是一類，裡面放置著所有使用者分組資訊。其餘以 [arm:/] 開頭的是另外一類，每一段就是對應著專案的一個目錄，其目錄相關許可權，就在此段內設置。

首先，我們將人員分組管理，以便以後由於人員變動而需要重新設置許可權時候，儘量少改動東西。我們一共設置了5個用戶分組，分組名稱統一採用 g_ 首碼，以方便識別。當然了，分組成員之間採用逗號隔開:

[groups]

# 任何想要查看所有文檔的非本部門人士

g_vip = morson

# 經理

g_manager = michael

# 北京辦人員

g_beijing = scofield

# 上海辦人員

g_shanghai = lincon

# 總部一般員工

g_headquarters = rory, linda

# 小秘，撰寫文檔

g_docs = linda

注意到沒有， linda 這個帳號同時存在“總部”和“文檔員”兩個分組裡面，這可不是我老眼昏花寫錯了，是因為 svnserve.exe 允許我這樣設置。它意味著，這個傢伙所擁有的許可權，將會比他的同事 rory 要多一些，這樣的確很方便。具體多了哪些呢？請往下看！

 

3   authz.conf 之專案根目錄

接著，我們對專案根目錄做了限制，該目錄只允許arm事業部的經理才能修改，其他人都只能眼巴巴的看著:

[arm:/]

@g_manager = rw

* = r

 

• [arm:/] 表示這個目錄結構的相對根節點，或者說是 arm 專案的根目錄


• 這裡的 @ 表示接下來的是一個組名，不是用戶名。你當然也可以將 @g_manager=rw 這一行替換成 michael=rw ，而表達的意義完全一樣。


• * 表示“除了上面提到的那些人之外的其餘所有人”，也就是“除了部門經理外的其他所有人”，當然也包括總經理那個怪老頭


• * = r 則表示“那些人只能讀，不能寫”

 

4   authz.conf 之項目子目錄

然後，我們要給總部人員開放日誌目錄的讀寫許可權:

[arm:/diary/headquarters]

@g_manager = rw

@g_headquarters = rw

@g_vip = r

* =

 

• 我敢打賭，設計svn的傢伙們，大部分都是在 unix/linux 平臺下工作，所以他們總喜歡使用 / 來標識子目錄，而完全忽視在 MS Windows 下是用 \ 來做同樣的事情。所以這兒，為了表示 arm\diary\headquarters 這個目錄，我們必須使用 [arm:/diary/headquarters] 這樣的格式。


• 這裡最後一行的 *= 表示，除了經理、總部人員、特別人士之外，任何人都被禁止訪問本目錄。這一行是否可以省略呢？


• 之所以這兒需要將 @g_vip=r 一句加上，就是因為存在上述這個解釋。如果說你沒有明確地給總經理授予讀的權力，則他會和其他人一樣，被 * 給排除在外。


• 如果眾位看官中間，有誰玩過防火牆配置的話，可能會感覺上述的配置很熟悉。不過這裡有一點與防火牆配置不一樣，那就是各個配置行之間，沒有 先後順序 一說。也就是說，如果我將本段配置的 *= 這一行挪到最前面，完全不影響整個配置的最終效果。


• 請注意這兒，我們並沒有給 arm\diary 目錄設置許可權，就直接跳到其子目錄下進行設置了。我當然是故意這樣的，因為我想在這兒引入“繼承”的概念。


• 許可權具備繼承性 任何子目錄，均可繼承其父目錄的所有權限，除非它自己被明確設置了其他的許可權。也就是說，在 arm 目錄設置許可權後， arm\diary 目錄沒有進行設置，就意味著它的許可權與 arm 目錄一樣，都是只有經理才有權讀寫，其他人只能幹瞪眼。


• 【 * = 是否可以省略】【用例子引入覆蓋】【單用戶許可權的繼承問題】【父目錄許可權集成與全面覆蓋問題】

 

現在來看看

好了，我們現在掌握了“繼承”的威力，它讓我們節省了不少敲鍵盤的時間。可是現在又有一個問題了，

屬性具備覆蓋性質子目錄若設置了屬性，則完全覆蓋父目錄。

 

5   authz.conf 的其他注意點

1. 父目錄的 r 許可權，對子目錄 w 許可權的影響

把這個問題專門提出來，是因為在1.3.1及其以前的版本裡面，有個bug，即為了子目錄的寫許可權，專案首目錄必須具備讀許可權。因此現在使用了1.3.2版本，就方便了那些想在一個代碼庫存放多個相互獨立的專案的管理員，來分配許可權了。比如說央舜公司建立一個大的代碼庫用於存放所有員工日誌，叫做 diary，而arm事業部只是其中一個部門，則可以這樣做:

[diary:/]

@g_chief_manager = rw

[diary:/arm]

@g_arm_manager = rw

@g_arm = r

這樣，對於所有arm事業部的人員來說，就可以將 svn://192.168.0.1/diary/arm 這個URL當作根目錄來進行日常操作，而完全不管它其實只是一個子目錄，並且當有少數好奇心比較強的人想試著 checkout 一下 svn://192.168.0.1/diary 的時候，馬上就會得到一個警告“Access deni”，哇，太酷了。

1. 默認許可權

如果說我對某個目錄不設置任何許可權，會怎樣？馬上動手做個試驗，將:

[diary:/]

@g_chief_manager = rw

改成:

[diary:/]

# @g_chief_manager = rw

這樣就相當於什麼都沒有設置。在我的 svn 1.3.2 版本上，此時是禁止任何訪問。也就是說，如果你想要讓某人訪問某目錄，你一定要顯式指明這一點。這個策略，看起來與防火牆的策略是一致的。

1. 唯讀許可權帶來的一個小副作用

若設置了:

[arm:/diary]

* = r

則svnserve認為，任何人，都不允許改動diary目錄，包括刪除和改名，和新增。

也就是說，如果你在專案初期創建目錄時候，一不小心寫錯目錄名稱，比如因拼寫錯誤寫成 dairy，以後除非你改動 authz.conf 裡面的這行設置，否則無法利用 svn mv 命令將錯誤的目錄更正。

 

改進

1   對中文目錄的支援

上午上班的時候，Morson 來到 Michael 的桌子前面，說道：“你是否可以將我們的北京辦、上海辦目錄，改成用中文的，看著那些拼音我覺得很難受？” Michael 心想，還好這兩天剛瞭解了一些與 unicode 編碼相關的知識，於是微笑地回答：“當然可以，你明天下午就可以看到中文目錄名稱了。”

1. 使用 svn mv 指令，將原來的一些目錄改名並 commit 入代碼庫，改名後的目錄結構如下:


2. arm


3. ├─工作日志


4. │  ├─總部人員


5. │  ├─北京辦


6. │  └─上海辦


7. ├─公司公共檔參考目錄


8. └─暫存檔案存放處


9. 修改代碼庫的 authz.conf 檔，將相應目錄逐一改名


10. 使用 UltraEdit 將 authz.conf 檔轉換成不帶 BOM 的 UTF-8 格式

將設定檔轉換成 UTF-8 格式之後，Subversion 就能夠正確識別中文字元了。但是這裡需要注意一點，即必須保證 UTF-8 檔不包含 BOM 。BOM 是 Byte Order Mark 的縮寫，指 UNICODE 檔頭部用於指明高低位元組排列順序的幾個字元，通常是 FFFE ，而將之用 UTF-8 編碼之後，就是 EFBBBF 。由於 UTF-8 檔本身不存在位元組序問題，所以對 UTF-16 等編碼方式有重大意義的 BOM，對於 UTF-8 來說，只有一個作用——表明這個檔是 UTF-8 格式。由於 BOM 會給文本處理帶來很多難題，所以現在很多軟體都要求使用不帶 BOM 的 UTF-8 檔，特別是一些處理文本的軟體，如 PHP、 UNIX 指令檔等，svn 也是如此。

目前常用的一些文本編輯工具中，MS Windows 自帶的“記事本”裡面，“另存為”菜單保存出來的 UTF-8 格式檔，會自動帶上 BOM 。新版本 UltraEdit 提供了選項，允許使用者選擇是否需要 BOM，而老版本的不會添加 BOM。請各位查看一下自己常用的編輯器的說明文件，看看它是否支持這個功能。

利用 UltraEdit ，我們可以將 BOM 去掉。方法是，首先利用“UTF-8 TO ASCII”功能表將檔轉換成本地編碼，通常是GB2312碼，然後再使用“ASCII TO UTF-8(UNICODE Editing)”來轉換到 UTF-8 即可。

摘自:http://www.blogjava.net/coldtear/archive/2006/09/05/67808.aspx

補充:

在上一篇帖子中介紹了Subversion版本控制軟體的安裝方法，另外還轉貼了一篇Subversion許可權控制的文章，出於工作的需要和學習態度的角度，還是希望自己到手來體驗Subversion許可權控制的魅力。

        如果對Subversion安裝有疑問的話，請看作者另一篇帖子：http://www.blogjava.net/coldtear/archive/2006/08/04/61668.aspx，在這篇帖子裡詳細介紹了Subversion的安裝步驟。

        在作者看了轉貼（《Subversion許可權詳解》）文章後，按照文章中的方法進行設置後，出現了一些問題，總是提示沒有許可權這樣的錯誤，錯誤提示為：“錯誤 Authorization failed”，對設定檔進行一些修改後，終於可以實現許可權控制了，這裡將作者碰到問題後的解決辦法寫出來，希望能給和我碰到同樣問題的朋友些幫助。

        如果您按照http://www.blogjava.net/coldtear/archive/2006/09/05/67808.aspx這篇文章設置後，也提示沒有許可權的錯誤，那麼請您按照下面的方法操作。

修改conf\authz檔如下，主要是路徑的修改：

[groups]

g_vip = morson

g_manager = michael

g_beijing = scofield

g_shanghai = lincon

g_headquarters = rory, linda

g_docs = linda

#這裡多加了一個根目錄的許可權控制描述

[/]

@g_manager = rw

* =



#以下部分對路徑做了一些修改

[/arm]

@g_manager = rw

* = r



[/arm/diary/headquarters]

@g_manager = rw

@g_headquarters = rw

@g_vip = r

* =



[/arm/diary/beijing]

@g_manager = rw

@g_beijing = rw

@g_vip = r

* =



[/arm/diary/shanghai]

@g_manager = rw

@g_shanghai = rw

@g_vip = r

* =



[/arm/ref]

@g_manager = rw

@g_docs = rw

* = r



[arm:/temp]

* = rw

經過這樣的修改後，訪問時不會再報沒有許可權的錯誤，可以定制自己的許可權控制了。

Subversion對中文目錄的支援是非常好的，按照文章中的方法，可以很輕鬆的進行中文目錄的許可權控制，

當然，在保存authz檔時一定不要忘記選擇保存為“UTF-8 無BOM”。

Subversion 實務建議

蔡煥麟

huanlin.tsai at msa.hinet.net

Revision: 1.0  (Mar-18-2005)

---

實務 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 應用程式為例，參考下列步驟：

1. 
   

   先大致建構出網站的雛形，檔案目錄結構大致底定之後，才將檔案匯入檔案庫。

   
   


2. 
   

   建立檔案庫，並且準備匯入檔案庫。有一些檔案可能是你不希望進行版本控管的，因為當其他小組成員更新這些檔案之後，可能會造成他的開發環境出問題，例如： 無法編譯或執行程式等。不管是什麼原因，只要你有不想要放入檔案庫的檔案，就在匯入檔案庫之前，先把整個專案的檔案複製一份到一個暫存目錄下（c:\ temp），然後把 c:/temp 中所有不想控管版本的檔案刪除掉，然後再匯入檔案庫。匯入完成後把 c:/temp 底下的檔案全部刪除。

   
   


3. 
   

   取出專案。先把整個專案的檔案*搬移*到 c:/temp 底下，接著從檔案庫取出（check out）專案，假設取出至 d:/myprj 目錄下。

   
   


4. 
   

   把 c:/temp 底下的所有檔案複製到 d:/myprj，注意所有已經存在的檔案都不要覆蓋掉，亦即只複製新的檔案過去。這些新的檔案並未加入版本控制，你可以把它們加入忽略清單（ignore list）裡面，以後這些檔案就不會被存入檔案庫了。

   
   

摘自:http://www.dotblogs.com.tw/huanlin/archive/2008/04/23/3200.aspx