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帮助文件。