York 's Bookmarks tagged book → View Popular

You are here: Diigo Home > York 's Bookmarks

Expand All 1 - 20 of 170 Next › Last »

New Directions in Statistical Signal Processing

Tags: book, brain, choice, signal, statistics on 2008-02-23 -All Annotations (0) -About

more frombooks.google.com

14Expand

《机器人》第三章－能力和显现

Tags: 5star, AI, book, computer, memory, robot, trend on 2008-02-17 -All Annotations (0) -About

in list: 5 Star

more fromwww.yrobot.net

三十年的计算机视觉的历程表明，1 MIPS的机器能从实时图像中提取简单的特征量───在杂色背景里跟踪白线或白点。10 MIPS的机器能跟随复杂的灰度区，巡航导弹、灵巧炸弹和早期的自驾驶大蓬车证实了这点。100 MIPS的机器恰好能追踪路面上不可预测的特征量，Navlab在长距离的行程证实了这点。1000 MIPS的机器完全能识别三维空间中带纹理的粗糙物体，某些中分辨率的立体视觉程序解释了这个问题，也包括我的程序。几个“垃圾箱挖掘”程序认为，10000 MIPS的机器能从杂乱中找到三维物体，并且高分辨率的立体视觉程序用10 MIPS的机器在1小时内演示了这一点。随着计算机速度和内存的增大，数据量问题逐渐不再是问题。
除了纯粹的运算规模，也得考虑其他因素。对1 MIPS的机器，最适用的程序是能有效处理检测数据的手工程序。
机器人视觉程序想要聪相应图像中得到一个边缘检测或移动检测数据的话，需执行100条计算机指令。一百万次检测则对应执行一亿条指令，1000MIPS的机器1秒能重复十次上述过程，基本上可与人的视网膜相比，新型高端个人计算机刚好能达到这个性能。
程序的实现不但取决于机器的速度，而且还受内存的制约。令人惊奇的是，在计算机发展史中，内存和速度比是非常恒定的
我们将内存容量除以速度定义为“时间常数”，粗略表示计算机扫描内存一次需要的时间。1兆字节/1 MIPS表示的结果是1秒。若机器的内存不能满足速度要求，这是新机器典型的情况，似乎运算速度很快，但会不必要地局限于小程序。若机器内存相对速度过剩，可以说它的商业可行性到了尽头，虽能运算大程序，但出奇的慢
先前已得出一亿MIPS能模仿人的功能这一结论，在这里做比较的话，前面所述的兆字节/MIPS的原则似乎在神经系统中也成立！交互的机器好象是神经系统的外延，遵从同样的时间常数。与其用机器与外界交互，不如让不同速度/存储比的人来完成
视听处理器和高性能飞行器等的控制器需要反就迅速，所以每兆字节相应很多MIPS。自动数据库和时变的安全摄像等问题涉及到慢速机器，每个MIPS会对应很多兆字节
飞虫似乎比人类反应快好几倍，MIPS的相对量要大一些。动物的情况也是这样，细胞间靠电化学和酶的方式传递信号。尽管植物细胞与动物神经元有本质的区别，一些植物细胞间似乎也能通讯。有一天，我们可能发现植物能记忆许多信息，但处理缓慢
二战后，计算机容量每两年翻一番。但进入20世纪80年代，每18个月计算机性能就要翻倍，20世纪90年代后期似乎缩短为12个月
通用性的实现是需要代价的。一个通用机器需要十倍或十倍以上的资源来完成一项专用任务。如果任务改变，通用机器可以被重新编程，而专用机器就得被淘汰。
以目前的发展速度，类似人的机器人所需要的计算机将在21世纪20年代出现。
实现高级计算的关键是微型化，因为小部件的惯性小，在同等能量下运行更快，在给定空间中能集成更多内容
集成芯片不但在持续发展，而且在加速前进。制作集成电路的短波长的光被替代，制作中使用了更精确方法来嵌入混杂成份。集成电路的电压在减小，采用了更好的绝缘体、屏蔽方法、散热手段，电路上出现了更有效的晶体管、更密的管腿模式和不辐射的包装材料。如果有钱来刺激的话，总会有办法。事实上，方法在实验室里早有了。因为工程师们当时还没注意这些，他们正在完善已有的技术。当根本问题出现，他们才感到忧虑。当需求的呼声很高时，巨大研究成果会转变为现实的生产。
传统晶体管电路依赖于大量电子的流动，当规模很小时，会引起状态波动。但采用单电子晶体管和量子设备可以解决这项难题，它们的工作原理是量子波干涉。这些新设备越小，工作得就越好。干涉图式很适用目前的电路规模，它只用很小能量就可将电子从一边撞到另一边，从而完成操作。因此，这些电路可以在温度很低的环境下工作。这种方法能集成到0.01微米，量子交换在室温下就能进行。

19Expand

《机器人》第二章－小心！机器车辆！

Tags: AI, book, robot on 2008-02-17 -All Annotations (0) -About

more fromwww.yrobot.net

从1948年到1951年，英国心理学家沃尔特（W.Grey Walter）在英国造了六个电子乌龟，它们都带有超微型电子管大脑、旋转光电眼睛、接触开关式触角6。它们能在行走时避开障碍，在有特定光线召唤时能返回出发地。当几只小乌龟在一块时，它们会对彼此间的控制光线和触觉信号有所反应，表现出意想不到的社会行为，例如跳舞。
对于机器而言，计算要比推理容易得多，推理又要比感知和行动容易得多。为什么难易顺序正好与人相反呢？在十亿年的进化过程中，人类祖先的第一个进化选择都为了能在逆境的竞争中赢得生命要素，常常用一生的时间在竞争中更有效地感知和行动。达尔文的进化过程使人类的大脑具有获取和行动的特殊本领───这点因为太平常而常被忽略。
在20世纪的大部分时间里，每二十年机器计算力就会有上千倍的提高
目前，控制最好的商业机器人的计算机能够产生昆虫级的行为。它们的耗资不少，社会用途却很少，仅在工厂作为喷涂车、点焊车、安装电子器件和将东西移来移去
在未来十年中，机器全面智能化的进程将大大加速，我相信机器人数量会大增，应用范围会慢慢拓宽以满足普遍要求，最终成为通用机器人
许多任务似乎只需两个基本的图像操作就能完成，一是挑选出好的特征集（图像中许有特别的区域），另一个是对同一区域从不同视角来寻找。
移动机器人是这一新生的计算机控制机器人领域中的最年轻一代，并在1985年后成为此领域中的主角。1985年前为数不多的工作重点之一是阿波罗登月计划
三角测量、障碍检测、机器人运动演绎可以确定三维位置。我寻找实现这些想法的快速算法。采用空间压缩图像技术可完成大量工作，4、16、64以及更多像素的平方被平均为一个数，然后用汇编语言巧妙地编码，而我的算子能在一幅图中挑出许多有用特征，并得到另一幅图。整个过程计算机大约只用10秒钟
不对物体的位置进行分类，而是积累位置的“物体性”。尽管特别物体的特性甚至存在与否总被怀疑，可以肯定地认为机器人周围的位置是存在的，能被当作永久性的“存储桶”，以稳定地积累哪怕是内容的一丁点迹象。
机器人周围的的区域被分成栅格。程序给栅格的每个单元赋以数值代表积累的证据，也就是说，相应的单元包括一些内容或什么都没有。随着每次声纳激励，含有信息的单元被更新。在回波距离处的单元被占据（因为此处的任何物都将导致更短的回波）。声音强度和检测可靠性随着声纳离中心点的距离增大而减弱，所以得到的证据量也据此发生变化。
在运算速度为1/2 MIPS的丹宁机器人上，我们研制了能进行每秒十次声纳反馈信息处理的有效程序。操纵机器人的关键一步，即校正同一区域的两幅映像图，需要3秒钟
实验揭示，在狭窄而墙壁光滑的走廊里（恰与我们实验室杂乱环境不同）声波被不断反射，类似光线在充满镜子的大厅里的情况，此时大部分的反馈信息是不正确的，得出的映像图也不会有价值。处理程序是以声纳单元的分类为基础编写的，而此时并不能表明声纳数据真正给出环境信息。
在三维空间中，这些是一致的，不会出现模糊现象，栅格的分辨率会更高，单元内容会更确定。在二维空间中，一把椅子只是占据若干个单元的模糊东西，无法与其它具有同样尺寸的物体区分。在三维空间中，椅子就会有座位、椅腿、椅背，能由形状确认。三维图像可以使程序规划复杂路径，不仅可以四处迂回行进，而且能跨越障碍。视觉出错的可能性变得微乎其微。
广角镜覆盖面很广，但它产生明显的“鱼眼”失真。到了1995年，我才编写了克服此不足的程序。程序通过摄像机视察几百个黑点的校准模型，得到一个“纠正”函数，将原始图像校正为一个理想的几何图
20世纪80年代后期，状态低迷的“基于模型”（或“基于图像”）机器人人面临着基本问题。在麻省理工学院，精力充沛且善于表演的罗德.布鲁克斯（Rod Brooks）声称，基于模型的方法不切合实际，并示范了如何从没有模型的机器人人获取复杂行为。布鲁克斯的机器被巧妙设计的多反射层或行为集所控制，类似格雷.沃尔特的小乌龟或霍普金斯野兽，但更为复杂些。在行为集中，一种元素可能使机器人避开障碍，而根据检测，另一种元素或许使机器人沿墙行走。有些元素对另一些元素有所响应或无视它们。每个元素其实是适度分享处理器的简单程序，典型地，可以处理许多行为元素的机器人也许有1 MIPS的运算能力。自然界中的昆虫似乎被这种方式所控制，每个动作都由几百个神经元的神经节产生。布鲁克斯的机器人动作很像昆虫，当他的实验室开始研制六条腿行走的微型机器人时更说明了这点
但是新奇感过后，人们不得不承认，在完成复杂动作方面，基于行为的机器人可靠性并不比集成多控制器的机器人要好
20世纪90年代，基于模型的机器人可以在室内行驶，也可穿越乡村。它们含有一些反射行为集的元素，用于避开障碍和处理险情。也许受此影响，布鲁克斯研制了机器人“Cog”.它被大量可学习的反射行为所控制。迄今为止，它可以通过学习来用视觉跟踪物体，并抓获物体。与我们人类的神经系统很相似，但我认为它的模仿是低层次的。需要足够运算时间的Cog，其方法思路也许有助于追溯人类的进化和发展，或许可以导致全智能机器。虽然如此，我认为模仿高层的抽象性是更快的一条途径，直接可以借鉴有用的计算机科学和工程的成果
大部分实用自动机必然是按基于行为的思路而研制的。尽管对可预测性的设计必然会降低逼真度，但用电线连接的机电继电器很像简单昆虫的神经节，五十年来，它们一直用于控制自动电梯和工业机器。从20世纪80年代开始，微处理器。系统复杂性在慢慢增大，但大部分控制器仍以简单的方式对刺激产生反应
环境中独立事件数量的增加可以降低误解概率。增加证据栅格信息的最好途径是，全部用三维处理。在二维处理中，高度不同的门把手和桌面等其他东西被测的总是不一致，可能只是一个模糊映像图。将处理单元的边长减小到10厘米左右，也不会有太大的效果

51Expand

Version Control with Subversion

Tags: SCM, SVN, book on 2007-09-14 -All Annotations (0) -About

more fromtwpug.net

Subversion 是一個自由/開放源碼的版本控制系統, 也就是說 Subversion 管理著隨時間改變的檔案.
這些檔案放置在一個中央 檔案庫 (repository) 中. 這個檔案庫
很像一個尋常的檔案伺服器, 不過它會記住每一次檔案的變動. 這樣你就可以把檔案回復到舊的版本, 或是瀏覽檔案的變動歷程.
許多人會把版本控制系統想像成某種 “時光機器”
CVS 只能追蹤單獨檔案的歷史, 不過 Subversion 實作了一個 “虛擬”
的版本控管檔案系統, 能夠依時間追蹤整個目錄的更動. 目錄和檔案都
被納入版本控管. 最後, 用戶端有真正可用的 move (移動) 與
copy 指令
Subversion 建立分支與標記的方法, 就只是複製該計畫,
使用的方法就像 hard-link 一樣. 所以這些動作只會花費很小, 而且是固定的時間
Subversion 使用二進制差異運算法, 來表示檔案的差異, 它對文字 (人類可理解的) 與二進制檔案 (人類無法理解)
兩類的檔案都一視同仁
讓 Subversion 檔案庫如此不同的原因, 在於 它會記住所有的更動: 每個檔案的每一個更動, 甚至是每一個目錄所作的更動,
像是目錄與檔案的新增, 刪除, 以及重新編排
用戶端自檔案庫讀取資料時, 它通常只會看到最新版本的檔案系統樹.
但是用戶端也可以看到早先的檔案系統.
舉例來說, 用戶端可以詢問歷史性的問題, 像是 "上個星期三,
這個目錄裡有什麼東西?", 或 "誰是最後一個更動這個檔案的人,
而且作了哪些更動?"
Subversion, CVS, 還有其它的版本控制系統使用一種 複製-修改-合併的模
型, 作為鎖定的取代方法
許多版本控制系統以鎖定-修改-解鎖的方式
來解決這個問題
要是 Sally 的更動真的與 Harry
的更動重疊的話呢?
這該怎麼辦呢? 這種情況稱為 衝突 (conflict),
通常也不會是多大的問題. 當 Harry 要求用戶端程式將最新的檔案庫更動,
合併到他自己的工作複本時, 他自己的檔案 A 會被標示為衝突的狀態:
他可以看到兩邊互相衝突的更動, 然後手動在這兩者之間作選擇
複製-修改-合併模型聽起來有點混亂, 但是實務上跑起來可是相當地平順. 使用者可以同時各自工作, 不需等待他人.
當他們同時處理同一個檔案時, 大多數的情況下, 這些同時產生的更動都不會互相重疊; 衝突是相當少見的. 而且解決衝突所需要的時間,
也遠低於鎖定系統所損失的時間
每一次檔案庫接受一個送交的更動, 就會讓檔案樹進入一個新的狀態,
稱之為 修訂版本.
每一個修訂版本都會被賦與一個唯一的, 比前一個修訂版號大一的自然數.
一個新建立的檔案庫的修訂版號為零, 其中除了空的根目錄外,
什麼都沒有
不同於許多其它的版本控制系統, Subversion
的修訂版號是對整個樹有效, 而不僅只於個別的檔案.
每一個修訂版號都可選取整個樹,
它對應到某個更動送交之後的特定狀態的檔案庫. 另一個思考的方式,
就是版號 N 表示是第 N 次送交之後的檔案庫的檔案系統狀態
你可以藉由 svn status,
svn diff, 以及 svn revert
這些命令, 來看看你所作的更動是什麼. 通常你會用前兩個命令,
來找你對工作複本所作的更動, 然後可能用第三個命令來復原這些更動
CVS 使用者: 別急著更新!

你可能曾用過 cvs update
來看看你對工作複本所作的更動. svn status
就可以得知所有你對工作複本所作過的更動的資訊—
不必存取檔案庫, 而且還不會不小心合併其它使用者發表的更動.

在 Subversion 中, update
就是作更動的動作—
它會將從你上次更新工作複本後所產生的所有更新,
通通更新到你的工作複本中. 你必須戒掉使用 update
以得知自己作過什麼修改的習慣
另一個檢視更動的方法, 是使用 svn diff 命令.
你可以得知切確修改的地方,
只要不帶引數執行 svn diff 即可
svn revert ITEM 的效果,
就跟自工作複本刪除 ITEM, 然後執行
svn update ITEM
是一樣的.
但是如果你要回復一個檔案, svn revert 有一個很重要的差異
— 它不需要與檔案庫溝通, 就能回復你的檔案
這三個命令 (svn status,
svn diff, 以及 svn revert)
都可以在沒有網路可用的情況下使用.
在你沒有網路連線的情況下, 還是可以管理進行中的更動
檔案庫並不會知道, 也不管你的更動是否有意義;
它只會檢查是否有人在你沒注意時, 也修改了你所更動的檔案.
如果有人也修改到了, 那麼整個送交就會失敗,
並以一則訊息提示你, 有一個或多個檔案已經過時了:
```
$ svn commit --message "Add another rule"
Sending        rules.txt
svn: Transaction is out of date
svn: Commit failed (details follow):
svn: out of date: `rules.txt' in txn `g'
$
```
此時, 你需要執行 svn update,
處理產生的合併或衝突,
然後再試著送交一次
Subversion 有一些命令, 可以幫助你維持檔案與目錄的平行分支.
它讓你藉由複製資料來產生分支, 並且會記住這些複本是彼此相關的.
它也會幫你從一個分支中, 重製更動到另一個分支去. 最後,
它還能夠讓工作複本的不同部份反映出不同的分支, 這樣你就能在你每日的工作中,
"混合搭配" 不同的發展路徑
建立一個分支相當地容易 — 利用 svn copy 命令,
在檔案庫中建立計劃的複本. Subversion 不僅能夠複製單一檔案,
整個目錄也沒有問題

現在介紹的是另一個建立分支較容易的方法, 我們該在一開始就告訴你:
svn copy 可以處理兩個 URL.

$ svn copy http://svn.example.com/repos/trunk/calc \
           http://svn.example.com/repos/branches/calc/my-calc-branch \
      -m "Creating a private branch of /trunk/calc"

Committed revision 341.

當你複製一個目錄時,
你不必擔心檔案庫會變得非常大 — Subversion 不會真的複製資料.
相反地, 它建立一個指向現存檔案樹的目錄項目.
如果你是一個 Unix 使用者, 這個概念就像 hard-link 一樣
這個工作複本沒有什麼特殊的地方; 它只是映射出另一個檔案庫的位置.
但是當你送交更動時, Sally 在更新時也不會看到它們. 她的工作複本是在
/trunk/calc.

讓我們假裝一個星期已經過去了, 而我們有以下的送交更動:
- 你修改了 /branches/calc/my-calc-branch/button.c,
  產生修訂版 342.
- 你修改了 /branches/calc/my-calc-branch/integer.c,
  產生修訂版 343.
- Sally 修改了 /trunk/calc/integer.c,
  產生修訂版 344
不像其它的版本控制系統, Subversion 的分支是以
正常的檔案系統目錄 存在於檔案庫裡,
而不是其它獨立的維度.

Subversion 內部並沒有 "分支" 的概念—只有複本而已.
如果你複製了一個目錄, 結果的目錄會是 "分支", 只是因為你
賦與它這個意義. 你可以把它想成不同的意義, 或是以不同的方式處理它,
但是對 Subversion 而言, 它只是一個因複製而產生的普通目錄而己.
現在該是使用 svn merge 命令的時候.
這個命令結果是很像 svn diff 命令 (這在第 3
章就介紹過了).
這兩個命令都可以比較兩個檔案庫裡物件, 並表示它們之間的差異
svn merge 幾乎是完全一樣的.
但是它不會在終端機上顯示差異,
而是直接當成 本地修改 套用到你的工作複本上:
```
$ svn merge -r 343:344 http://svn.example.com/repos/trunk/calc
U  integer.c

$ svn status
M  integer.c
```
如果你認為合併根本不是個好主意的話, 直接捨棄它, 以
svn revert 來回復本地更動
假裝你已經檢視過合併的更動, 你可以一如往常地使用
svn commit 來送交更動. 此時, 這個更動就被合併到你的
檔案庫分支. 在版本控制的術語中, 這個在不同的分支之間複製更動的動作,
稱為移植更動
svn merge
有一個優於 patch 程式的特殊功能.
patch 所使用的檔案格式有其限制; 它只能處理檔案的內容而已.
它沒有辦法表達 檔案樹 的變動, 諸如目錄與檔案的新增,
刪除, 或是更名. 假如說 Sally 的更動新增了一個目錄, 那麼
svn diff 的輸出完全無法顯示. svn diff
只能輸出功能有限制的修補格式, 所以有些東西就是無法顯示出來. ^[8]
但是 svn merge
命令可以藉由直接套用檔案樹的更動到你的工作複本中, 來表示這樣的更動
svn switch 命令可將現有的工作複本切換到不同的分支去.
雖然這個命令與分支運作沒什麼很直接的關係, 但是對使用者來說, 是個滿不錯的捷徑

建立一個簡單的標記

再一次地, svn copy 又來解救眾生了.
如果你想要建立一個完全符合 HEAD 修訂版的 /trunk/calc
的快照, 那就建立一個它的複本:

$ svn copy http://svn.example.com/repos/trunk/calc \
           http://svn.example.com/repos/tags/calc/release-1.0 \
      -m "Tagging the 1.0 release of the 'calc' project."

Committed revision 351.

Subversion 的檔案庫是個中央倉儲, 用來存放任意數量專案的受版本控管資料
建立一個 Subversion 的檔案庫出乎意料地簡單. Subversion 所提供的
svnadmin 工具, 有個專門處理這件事的子命令.
要建立一個新的檔案庫, 只要執行:
```
$ svnadmin create path/to/repos
```
這會在目錄 path/to/repos 裡建立一個新的檔案庫.
這個新的檔案庫會以修訂版 0 開始其生命週期, 裡面除了最上層的根目錄
(/), 什麼都沒有. 剛開始, 修訂版 0 還有一個單一的修訂版性質
svn:date, 會設定在檔案庫初建立的時間
svnadmin
的路徑引數只是一個普通的檔案系統路徑,
而不是像 svn 用戶端程式用來表示檔案庫的 URL.
svnadmin 與
svnlook 都被視為是伺服器端的工具 —
它們是在檔案庫所在的機器上, 對檔案庫作檢視或修改之用
svnlook 是 Subversion 提供的工具,
用來檢視檔案庫不同的修訂版與異動. 本程式完全不會試著去修改檔案庫 —
這是 “唯讀” 工具. svnlook
通常用在檔案庫掛勾程式中, 用來回報檔案庫即將送交的更動 (用在
pre-commit 掛勾時), 或剛送交的更動
(用在 post-commit 掛勾時).
檔案庫管理員也許會將這個工具用於診斷之用
Subversion 檔案系統將其資料散佈在數個資料庫表格之中, 通常只有
Subversion 管理員了解 (也只有他們想了解). 但是有的時候,
我們需要將所有的資料, 或是部份的資料, 集合在單一可移植的平面檔.
Subversion 提供這樣的機制, 由兩個 svnadmin
子命令實作出來:
dump 以及 load.

傾印與載入 Subversion 檔案庫的最常見原因, 就是 Subversion 本身的改變.
隨著 Subversion 日漸成熟, 有時會因後端資料庫 schema 的改變, 導致
Subversion 與前一版的檔案庫不相容. 當你升級遇到這樣的相容性問題時,
我們建議以下列簡單的步驟來進行:
1. 使用你現有版本的 svnadmin,
  將檔案庫傾印至傾印檔案.
2. 升級至新版的 Subversion.
3. 將舊的檔案庫移開, 在原處以 新版本 的
  svnadmin, 建立新的空檔案庫
4. 再利用 新版本 的 svnadmin,
  將你的傾印檔載入至剛剛建立的檔案庫.
5. 最後, 請記得將原來檔案庫的自訂部份複製到新的去, 包括
  DB_CONFIG 與掛勾命令稿. 你應該要檢查一下新版本
  Subversion 的發行備註, 看看從你上次更新後, 有沒有影響這些掛勾或設定選項的更動.
如果在傾印檔案庫時, 加上了 --incremental
選項, svnadmin
會將檔案庫的第一個傾印修訂版, 與檔案庫中前一個修訂版作比較,
就像其它被傾印的修訂版的處理方法一樣. 第一個修訂版的輸出,
就像傾印檔裡其它的修訂版輸出一樣 — 只會顯示該修訂版的更動部份而已.
這樣的好處, 是你可以建立幾個可連續載入的小傾印檔, 而不是一個很大的,
像這樣:
```
$ svnadmin dump myrepos --revision 0:1000 > dumpfile1
$ svnadmin dump myrepos --revision 1001:2000 --incremental > dumpfile2
$ svnadmin dump myrepos --revision 2001:3000 --incremental > dumpfile3
```
這些傾印檔可以透過下列一連串的命令, 載入到新的檔案庫中:
```
$ svnadmin load newrepos < dumpfile1
$ svnadmin load newrepos < dumpfile2
$ svnadmin load newrepos < dumpfile3
```
通常最好的修訂版備份是包含多種方式的. 你可以妥善運用完整備份與漸進備分的組合,
再加上電子郵件的送交檔案
要讓你的檔案庫透過 HTTP 供他人存取, 基本上你需要四個元件,
可從兩個套件中取得. 你需要 Apache 的 httpd 2.0,
它也包含了 mod_dav 的 DAV 模組.
Subversion, 以及包含的 mod_dav_svn
檔案系統供應模組
如果你計劃支援多個 Subversion 檔案庫, 而它們都有著共同的本地磁碟路徑,
你可以使用另一種指令 SVNParentPath, 指示它們共同的父路徑.
舉個例子, 如果你知道你會在路徑 /usr/local/svn
之下建立多個 Subversion 檔案庫, 並以類似 http://my.server.com/svn/repos1,http://my.server.com/svn/repos2 等等的 URL 供人存取,
你可以使用下列例子中的 httpd.conf 設定語法:
```
<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
</Location>
```
使用前述的語法, Apache 會將所有路徑以 /svn/
開始的 URL 都交給 Subversion DAV 供應模組處理, 它會假設任何以
SVNParentPath 指令指定的目錄都是 Subversion 檔案庫.
不像 SVNPath,
這個相當便利的語法可以讓你在建立新的檔案庫時, 仍舊不必重跑 Apache.
LoadModule dav_svn_module modules/mod_dav_svn.so
Apache 提供了 htpasswd 工具程式,
來管理接受的使用者名稱與密碼
$ ### 第一次: 以 -c 建立檔案
$ htpasswd -c /etc/svn-auth-file harry
New password: *****
Re-type new password: *****
Adding password for user harry
$ htpasswd /etc/svn-auth-file sally
New password: *******
Re-type new password: *******
Adding password for user sally
$
掛勾 (hook) 是某些檔案庫事件所觸發的程式,
像是建立新的修訂版時, 修改未納入版本控制的性質時.
每一個掛勾都會得到足夠的資訊, 可以分辨出得到的是什麼事件,
針對哪個 (哪些) 目錄, 以及被誰觸發.
依掛勾輸出或傳回狀態的不同, 掛勾程式可以繼續, 停止, 或是暫停該動作