Bubble-Up Method

This section provides a conversational explanation of how the repository actually stores and revisions file trees. It's not critical knowledge for a programmer using the Subversion Filesystem API, but most people probably still want to know what's going on “under the hood” of the repository.

Suppose we have a new project, at revision 1, looking like this (using CVS syntax):

prompt$ svn checkout myproj
U myproj/
U myproj/B
U myproj/A
U myproj/A/fish
U myproj/A/fish/tuna
prompt$

Only the file tuna is a regular file, everything else in myproj is a directory.

Let's see what this looks like as an abstract data structure in the repository, and how that structure works in various operations (such as update, commit, and branch).

In the diagrams that follow, lines represent parent-to-child connections in a directory hierarchy. Boxes are "nodes". A node is either a file or a directory – a letter in the upper left indicates which kind. A file node has a byte-string for its content, whereas directory nodes have a list of dir_entries, each pointing to another node.

Parent-child links go both ways (i.e., a child knows who all its parents are), but a node's name is stored only in its parent, because a node with multiple parents may have different names in different parents.

At the top of the repository is an array of revision numbers, stretching off to infinity. Since the project is at revision 1, only index 1 points to anything; it points to the root node of revision 1 of the project:

                    ( myproj's revision array )
       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |
          |
       ___|_____
      |D        |
      |         |
      |   A     |      /* Two dir_entries, `A' and `B'. */
      |    \    |
      |   B \   |
      |__/___\__|
        /     \
       |       \
       |        \
    ___|___   ___\____
   |D      | |D       |
   |       | |        |
   |       | | fish   |   /* One dir_entry, `fish'. */
   |_______| |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |  /* One dir_entry, `tuna'. */
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |   /* (Contents of tuna not shown.) */
                   |________|

What happens when we modify tuna and commit? First, we make a new tuna node, containing the latest text. The new node is not connected to anything yet, it's just hanging out there in space:

                         ________
                        |F       |
                        |        |
                        |        |
                        |________|

Next, we create a new revision of its parent directory:

                 ________
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

We continue up the line, creating a new revision of the next parent directory:

              ________
             |D       |
             |        |
             | fish   |
             |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

Now it gets more tricky: we need to create a new revision of the root directory. This new root directory needs an entry to point to the “new” directory A, but directory B hasn't changed at all. Therefore, our new root directory also has an entry that still points to the old directory B node!

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |
          |
       ___|_____             ________
      |D        |           |D       |
      |         |           |        |
      |   A     |           |   A    |
      |    \    |           |    \   |
      |   B \   |           |   B \  |
      |__/___\__|           |__/___\_|
        /     \               /     \
       |    ___\_____________/       \
       |   /    \                     \
    ___|__/   ___\____              ___\____
   |D      | |D       |            |D       |
   |       | |        |            |        |
   |       | | fish   |            | fish   |
   |_______| |___\____|            |___\____|
                  \                     \
                   \                     \
                 ___\____              ___\____
                |D       |            |D       |
                |        |            |        |
                | tuna   |            | tuna   |
                |___\____|            |___\____|
                     \                     \
                      \                     \
                    ___\____              ___\____
                   |F       |            |F       |
                   |        |            |        |
                   |        |            |        |
                   |________|            |________|

Finally, after all our new nodes are written, we finish the “bubble up” process by linking this new tree to the next available revision in the history array. In this case, the new tree becomes revision 2 in the repository.

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |        \
          |         \__________
       ___|_____             __\_____
      |D        |           |D       |
      |         |           |        |
      |   A     |           |   A    |
      |    \    |           |    \   |
      |   B \   |           |   B \  |
      |__/___\__|           |__/___\_|
        /     \               /     \
       |    ___\_____________/       \
       |   /    \                     \
    ___|__/   ___\____              ___\____
   |D      | |D       |            |D       |
   |       | |        |            |        |
   |       | | fish   |            | fish   |
   |_______| |___\____|            |___\____|
                  \                     \
                   \                     \
                 ___\____              ___\____
                |D       |            |D       |
                |        |            |        |
                | tuna   |            | tuna   |
                |___\____|            |___\____|
                     \                     \
                      \                     \
                    ___\____              ___\____
                   |F       |            |F       |
                   |        |            |        |
                   |        |            |        |
                   |________|            |________|

Generalizing on this example, you can now see that each “revision” in the repository history represents a root node of a unique tree (and an atomic commit to the whole filesystem.) There are many trees in the repository, and many of them share nodes.

Many nice behaviors come from this model:

1. Easy reads. If a filesystem reader wants to locate revision X of file foo.c, it need only traverse the repository's history, locate revision X's root node, then walk down the tree to foo.c.

2. Writers don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. The new tree only becomes visible to readers after the writer makes its final “link” to the repository's history.

3. File structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.

Let's demonstrate the last point by renaming the tuna to book.

We start by creating a new parent “fish” directory, except that this parent directory has a different dir_entry, one which points the same old file node, but has a different name:

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |        \
          |         \__________
       ___|_____             __\_____
      |D        |           |D       |
      |         |           |        |
      |   A     |           |   A    |
      |    \    |           |    \   |
      |   B \   |           |   B \  |
      |__/___\__|           |__/___\_|
        /     \               /     \
       |    ___\_____________/       \
       |   /    \                     \
    ___|__/   ___\____              ___\____
   |D      | |D       |            |D       |
   |       | |        |            |        |
   |       | | fish   |            | fish   |
   |_______| |___\____|            |___\____|
                  \                     \
                   \                     \
                 ___\____              ___\____      ________
                |D       |            |D       |    |D       |
                |        |            |        |    |        |
                | tuna   |            | tuna   |    | book   |
                |___\____|            |___\____|    |_/______|
                     \                     \         /
                      \                     \       /
                    ___\____              ___\____ /
                   |F       |            |F       |
                   |        |            |        |
                   |        |            |        |
                   |________|            |________|

From here, we finish with the bubble-up process. We make new parent directories up to the top, culminating in a new root directory with two dir_entries (one points to the old “B” directory node we've had all along, the other to the new revision of “A”), and finally link the new tree to the history as revision 3:

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |        \        \_________________
          |         \__________               \
       ___|_____             __\_____        __\_____
      |D        |           |D       |      |D       |
      |         |           |        |      |        |
      |   A     |           |   A    |      |   A    |
      |    \    |           |    \   |      |    \   |
      |   B \   |           |   B \  |      |   B \  |
      |__/___\__|           |__/___\_|      |__/___\_|
        /  ___________________/_____\_________/     \
       |  / ___\_____________/       \               \
       | / /    \                     \               \
    ___|/_/   ___\____              ___\____      _____\__
   |D      | |D       |            |D       |    |D       |
   |       | |        |            |        |    |        |
   |       | | fish   |            | fish   |    | fish   |
   |_______| |___\____|            |___\____|    |___\____|
                  \                     \             \
                   \                     \             \
                 ___\____              ___\____      ___\____
                |D       |            |D       |    |D       |
                |        |            |        |    |        |
                | tuna   |            | tuna   |    | book   |
                |___\____|            |___\____|    |_/______|
                     \                     \         /
                      \                     \       /
                    ___\____              ___\____ /
                   |F       |            |F       |
                   |        |            |        |
                   |        |            |        |
                   |________|            |________|

For our last example, we'll demonstrate the way “tags” and “branches” are implemented in the repository.

In a nutshell, they're one and the same thing. Because nodes are so easily shared, we simply create a new directory entry that points to an existing directory node. It's an extremely cheap way of copying a tree; we call this new entry a clone, or more colloquially, a “cheap copy”.

Let's go back to our original tree, assuming that we're at revision 6 to begin with:

       ______________________________________________________
    ...___6_______7________8________9________10_________11_____...
          |
          |
       ___|_____
      |D        |
      |         |
      |   A     |
      |    \    |
      |   B \   |
      |__/___\__|
        /     \
       |       \
       |        \
    ___|___   ___\____
   |D      | |D       |
   |       | |        |
   |       | | fish   |
   |_______| |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

Let's “tag” directory A. To make the clone, we create a new dir_entry T in our root, pointing to A's node:

       ______________________________________________________
      |___6_______7________8________9________10_________11_____...
          |        \
          |         \
       ___|_____   __\______
      |D        | |D        |
      |         | |         |
      |   A     | |    A    |
      |    \    | |    |    |
      |   B \   | |  B |  T |
      |__/___\__| |_/__|__|_|
        /     \    /   |  |
       |    ___\__/   /  /
       |   /    \    /  /
    ___|__/   ___\__/_ /
   |D      | |D       |
   |       | |        |
   |       | | fish   |
   |_______| |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

Now we're all set. In the future, the contents of directories A and B may change quite a lot. However, assuming we never make any changes to directory T, it will always point to a particular pristine revision of directory A at some point in time. Thus, T is a tag.

(In theory, we can use some kind of authorization system to prevent anyone from writing to directory T. In practice, a well-laid out repository should encourage “tag directories” to live in one place, so that it's clear to all users that they're not meant to change.)

However, if we do decide to allow commits in directory T, and now our repository tree increments to revision 8, then T becomes a branch. Specifically, it's a branch of directory A which shares history with A up to a certain point, and then “broke off” from the main line at revision 8.

SYNOPSIS(總覽)

DESCRIPTION(描述)

從 httpd Apache web服務器獲取的資源只限于由 htpasswd 創建的文件中所列出的用戶使用. 該程序只能用于用戶名保存在平面文件的情況下. 要使用DBM數據庫,請參看 dbmmanage.

htpasswd 的加密密碼既可以使用針對Apache修改的MD5版本, 也可以使用系統的crypt()程序. 由 htpasswd 管理的文件可能同時包含兩種類型的密碼; 一些用戶記錄可使用MD5加密的密碼, 而另一些用戶記錄可在同一文件中使用通過 crypt()加密的密碼.

該手冊頁只列出了命令行的參數. 要獲得關于在 httpd 中配置用戶認證的必要指令的詳細情況, 可參看Apache手冊,它是Apache發布版本的一部分,你也可以在 <URL:http://www.apache.org/>上找到它. ?

OPTIONS(選項)

-b

使用批處理模式;也即,從命令行上獲取密碼而不給出提示.該選項在使用時應特別小心, 因為密碼是在命令行上清楚可見的.

-c

創建passwdfile.如果passwdfile 已經存在,那么它會重新寫入并刪去原有內容.

-m

密碼使用Apache修改的MD5算法. 使用這種算法加密的密碼可以移植到運行Apache 1.3.9或更新版本的任何平臺上(Windows,Unix,BeOS,等等). 在Windows和TPF上,該標識是默認的.

-d

密碼使用crypt()加密.這是除了Windows和TPF 之外的所有平臺上的默認值.盡管這可被所有平臺上的 htpasswd 支持,卻不被Windows和TPF上的 httpd 服務器所支持.

-s

密碼使用SHA加密方法.這種方式移植于Netscape服務器, 使用的是LDAP目錄交換格式(ldif).

-p

使用普通文本格式的密碼.盡管 htpasswd 可支持在所有平臺上創建這種格式的密碼, 卻只有Windows和TPF上的 httpd 守護程序能夠接受普通文本密碼.

passwdfile

包含用戶名和密碼的文件的名字. 如果給定了-c,那么會在其不存在的情況下創建該文件, 或者在其存在的情況下重新寫入并刪去原有內容.

username

在passwdfile中創建或更新的用戶名. 如果username在文件中不存在, 即創建一條記錄. 如果已經存在,則修改其密碼.

password

文件中加密和存儲的普通文本格式的密碼. 只用于-b標識.

EXIT STATUS(退出狀態)

EXAMPLES(示例)

為用戶jsmith添加或修改密碼. 會給出用戶輸入密碼的提示. 如果在Windows系統上執行, 密碼會使用修改的Apache MD5算法加密; 否則,會使用系統的 crypt()程序. 如果文件不存在, htpasswd 會不作任何修改并返回一條錯誤提示.

htpasswd -c /home/doe/public_html/.htpasswd jane

創建一個新的文件并將用戶jane記錄保存在其中. 會給出用戶輸入密碼的提示. 如果文件存在但不能夠讀取,或者不能夠寫入, 那么它不會作修改,而且 htpasswd 會顯示一條消息并返回一個錯誤狀態.

htpasswd -mb /usr/web/.htpasswd-all jones Pwd4Steve

使用MD5算法加密取自命令行的密碼, 并將其保存到指定的文件中.

SECURITY CONSIDERATIONS(安全考慮)

建議不要使用-b選項,因為使用該選項時未加密的密碼出現在了命令行上. ?

RESTRICTIONS(限制)

使用的MD5算法是Apache軟件特有的; 使用它加密的密碼對于其他Web服務器來說是不可用的.

用戶名限制在255個字節以內,而且不能包含字符':'. q.SH SEE ALSO(另見) httpd(8) 以及隨發布版本所帶的support/SHA1下的腳本.

第二步,修改apache的配置文件
接著打開Apache HTTP Server 的 httpd.conf（在 /conf/ 目錄下），先找到以下兩行：
#LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
把這兩行最前面的 '#' 字符刪除，然后把下面這行加到這些 LoadModule 指令的后面：
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
用記事本打開 Apache HTTP Server 的 httpd.conf，在文件最后面加上以下幾行:
<Location /svn>
??? DAV svn
??? SVNParentPath d:/svn
</Location>
其中d:/svn為你要建的倉庫的父目錄(必須為本地目錄),最好用雙引號引一下.

第三步,創建倉庫
根據apache的配置文件的設置建立目錄:d:/svn.然后我們就可以在下面建立倉庫了,創建方法如下:
c:\>svnadmin create d:/svn/repository（svn大寫的時候居然驗證訪問被拒絕）
命令執行成功之后,會在d:/svn/repository下面生成很多的文件和目錄

第四步,使用
重新啟動Apache Server
在瀏覽器中輸入網址:
http://localhost/svn/repository/
這時候,看到頁面顯示：

Revision 0: /
Powered by Subversion version 1.3.2 (r19776).





安裝成功，接下來將進行進一步的設置。

二、配置

1．? 以兩種方式運行

（1） 以apache方式運行
? svn使用apache的權限管理對檔案庫及目錄進行讀寫管理。
??htpasswd的調用:
??? 1)用cmd進入到Apache的bin目錄下,直接開始調用
??? 2)把htpasswd添加到系統變量里.
??
? 建立保存用戶名和密碼的文件
? htpasswd -c? svn-auth-filename? username1
? 然后，會提示輸入密碼，這里就加入了一個用戶了。然后再加一個用戶：
? htpasswd -m ?/svn-auth-filename username2
?
? 建立控制用戶訪問權限的文件svn-access-filename
?[svn1:/]?????????????? //這表示，倉庫svn1的根目錄下的訪問權限
?harry = rw???????????? // svn1倉庫harry用戶具有讀和寫權限
?sally = r?????????????? // svn1倉庫sally用戶具有讀權限
?[svn2:/]?????????????? //svn2倉庫根目錄下的訪問權限
?harry = r?????????????? // harry用戶在svn2倉庫根目錄下只有讀權限
?sally =?????????????? // sally用戶在 svn2倉庫根目錄下無任何權限
?[svn2:/src]?????????? //svn2倉庫下src目錄的訪問權限
?harry=rw????????????
?sally=r
?[/]????????????????? // 這個表示在所有倉庫的根目錄下
?* = r?????????????? // 這個表示對所有的用戶都具有讀權限
?[groups]?????????????? // 這個表示群組設置
?svn1-developers = harry, sally?????????? // 這個表示某群組里的成員
?svn2-developers = sally
?[svn1:/]???????????
?@svn1-developers = rw?????? // 如果在前面加上@符號，則表示這是個群組權限設置
?
然后修改httpd.conf配置：
<Location /svn>
DAV svn
SVNParentPath /svn
AuthType Basic
AuthName "Subversion repository"(注意引號)
AuthUserFile? svn-auth-filename （保存用戶名和密碼）
Require valid-user
AuthzSVNAccessFile? svn-access-filename（保存用戶訪問的權限策略）
</Location>
（注：）
svn-access-filename,svn-auth-filename 文件直接可以放到C:\Program Files\Apache Group\Apache2\下，這也是默認的目錄，置于其他目錄下，啟動apache server出現錯錯誤。
AuthUserFile文件需要用htpasswd工具創建、維護；AuthzSVNAccessFile 文件可以用Subversion創建倉庫以后，生成的conf文件夾下面的authz文件加以修改。
如果已經有一個apache服務，希望兩個apache服務同時運行，則修改其中一個的服務端口。
修改httpd.conf中的一行： Listen 80 將80改成其他不用的端口號

啟動apahce就可以通過
http://svnmachine-ip/svn/svn1
http://svnmachine-ip/svn/svn2
這兩個URL來訪問倉庫了，當然，要受權限的限制，必須是合法用戶才能訪問且具有相應的權限

（2） svnserve方式運行
這種方式的運行又可以分為以下兩種(這和vsftp有些相似)
1) standalone mode
直接運行 #svnserve –d
運行 lsof -i :3690可以看到SVN服務器已經在運行

2) xinetd mode
在/etc/xinetd.d/下生成svnserve文件，內容如下
service svnserve
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = svnpub? (最好建一個這樣的用戶管理svn)
server = /usr/local/bin/svnserve
server_args = -i
}
編輯 /etc/services 檔,加入底下兩行:
svnserve 3690/tcp # Subversion svnserve
svnserve 3690/udp # Subversion svnserve
重啟xinetd服務，運行 netstat -a|grep svnserve 可以看到SVN服務器已經在運行

默認下客戶可以以匿名方式通過svn://方式任意訪問檔案庫，為了限制其權限，比如只允許讀操作，可以通過修改檔案庫conf子目錄中的svnseve.conf文件來實現。
#vi /svn1/conf/svnseve.conf
將下面三行前的＃去掉
anon-access = none??????????? //則匿名用戶不可以通過svn://方式訪問檔案庫
auth-access = write????
password-db = passwd????????? //使用passwd中的用戶名和密碼進行認證，有一點不好的是這里面的密碼輸的是明文
authz-db = authz????????????? //使用authz中的權限控制策略，寫法如同apache中的svn-access-filename

如果想更強的安全性可以使用svn+ssh://訪問機制。
首當用戶通過svn+ssh://訪問時，服務器會自動啟動ssh認證機制，要求用戶輸入密碼，對于window用戶來說還需要安裝第三方軟件openssh，才可以采用這種機制。

2．? 將代碼導入項目倉庫。在要導入倉庫的目錄上面點擊右鍵，點擊TortoiseSVN項的子菜單Import…在URl里面填寫http://服務器IP/svn/project，這里project就是剛剛建立的項目倉庫，

在下面填入注釋，點擊OK，彈出提示輸入用戶名密碼對話框，填入flmn和password，就可以把代碼導入倉庫了。剛剛導入的文件并沒有顯示被svn管理，現在把這個目錄里文件都刪除，再在右鍵菜單里選擇SVN Checkout…就可以導出代碼，再看這個目錄，就有個小圖標在文件夾圖標下面了。

3．? 對于其它操作，和CVS差不多，這里就不贅述了。可以參考TortoiseSVN幫助文件。