1. 刚刚在本目录下执行一个提交，然后执行 "svn log"，怎么看不到最新的提交？
如果您是使用分布式版本控制工具（如 git, hg, bzr），或者使用 CVS 的用户，会对此现象感到非常奇怪。“明明是刚在本目录下执行了一次提交，为什么 "svn log"，看不到呢？”
原因分析:
问题的实质是 SVN 的混杂版本号。
执行 "svn status -v" 命令可以看到当前目录处于混杂版本状态。
不同的版本控制工具使用不同的方法记录本地工作目录下文件的状态
分布式版本控制工具在工作区的最顶级目录包含唯一一个控制目录（如 .git, .hg, .bzr ── 实际为版本库本身）
Subversion在每一个工作目录下都包含一个名为 .svn 的控制目录，记录着每一个文件以及当前目录的版本号
相比之下，Subversion虽然采用了全局版本号，但本地记录目录和文件的版本散布在各个 .svn 目录中
当刚刚完成一次提交，仅仅该次提交涉及的文件在 .svn 控制目录中记录的版本号是最新的，其它的文件包括目录本身的版本号还是旧的。
“难道提交不应该自动更新所有文件和目录状态么？”
但这是不合理的，可能由于他人的修改破坏当前工作区，因此只有主动执行 "svn update" 命令，才进行更新。
解决办法:
在目录下执行一次 "svn update"，之后再执行 "svn log"，就在日志中能够看到刚刚的提交。或者使用命令 "svn log -rHEAD:1" 也可以看到最新提交实践出现在 log 中。
2. 修改目录属性提交报错：“目录 “XXX” 已经过时”！而这个目录当前只有我一个人在改动，没有其他人修改。
问题重现:
修改当前目录下的文件，之后提交。提交完毕后，不要执行 "svn update"，直接修改当前目录的属性，当再次提交时报错：
正在发送 XXX svn: 提交失败(细节如下): svn: 目录 “/trunk/XXX” 已经过时
原因分析:
问题的实质仍然是 SVN 的混杂版本号。
执行 "svn status -v" 命令可以看到当前目录处于混杂版本状态。 前一次的提交，并未更新当前目录的版本号，从而导致当前目录的版本号不是最新。当修改目录属性并提交时，引发 “目录已经过时” 的错误。
解决方案：
在当前目录下执行 "svn update"，之后再执行提交。