今天遇到一个问题：使用svn提交的文件在服务器的目录里面没有同步。
问题的描述：
A：服务器端
B1,B2:客户端
B1更新到A上的文件只存在于.SVN上面，B2通过.SVN获取文件，更新本地，而.SVN的东西不会出现在A的目录文件夹里面，即服务器端只更新.SVN文件夹，不会更新其他的文件夹。
这个是我当时的问题描述，而我的问题描述基于对subversion原理的错误理解。我的错误理解如下图：
我将服务器目录与SVN版本库同时认为是SVN的服务器端部分，客户端先使用TortoiseSVN上传到服务器的目录，在服务器端的SVN响应客户端的操作，对比服务器端目录下的文件，将被修改的文件备份到SVN的版本库里面，执行对目录的覆盖过程。当然，这样理解就很难解释为什么服务器端的目录和SVN版本不同步的问题。
在蓝色解决之前我找到过一份Subversion的设计原理。
实际上当时并没有看懂，在蓝色解决了客户端和服务器端目录不同步的问题之后我才恍然大悟。如图示，客户端的工作拷贝先通过DAV,SVN,Local的几个方式，将数据传输到Subversion的仓库里面（把文件上传到SVN版本库后,上传的文件不再以文件原来的格式存储,而是被svn以它自定义的格式压缩成版本库数据,存放在版本库中）。这就是整个SVN的存储过程。更简单一些的说法就是
文件----Repository Access----DB数据库的数据。
当时看这张图一直是没有明白为什么图当中只画了更新到数据库而没有画服务器端的目录是如何更新的。最后蓝色解答了这个问题，实际上是使用hook做更新：
使用post-commit.tmpl，设置当subversion执行了commit命名的时候，在服务器的相应上执行svn
update，自动更新服务器端的相应目录，这里服务器端相应的目录就相当于是又一个客户端。过程如下图：
其中TortoiseSVN 的执行过程就是上面的设计原理图显示的过程。
这样，将服务器端的目录作为客户端直接手动update，就可以更新到最新版本的程序文件。
这次服务器端目录不同步的是因为文件有冲突，人工解决了冲突，服务器端就可以自动更新了...
参考附录：
记录下一些有用的链接：
PS.
1.引用对两种数据库的一些比较：
从svn1.2版本开始，svnadmin缺省使用fsfs文件系统后端创建版本库，不仅是fsfs方式简单，而且还有一些优点，下面是2者的优缺点详细分析，供君参考：
item
fsfs Berkeley DB
--------------------------------------------
从只读系统mount过来后的可用性 yes
no
-------------------------------------------
平台无关的存储
yes no
--------------------------------------------
从网络文件系统映射过来的可用性 yes no
---------------------------------------------
占用空间大小
larger Smaller
----------------------------------------------
版本数量的可测量性 Depends
on FS No problems
-----------------------------------------------
速度：checkout最新代码 slow
fast
------------------------------------------------
组访问权限的处理
No problems Umask problem
-------------------------------------------------
软件成熟度
2004 2001
-------------------------------------------------
从上表来看，总体上fsfs优势更多一些。
所以我们创建库时建议采用fsfs方式。
| 
