This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.
Subversion 跟踪的是整棵目录树的变化, 而不仅仅是文件的内容, 这是 用 Subversion 替换 CVS 的一个重大理由.
对于前 CVS 用户而言, 能够对目录进行版本控制意味着:
命令 svn add 和 svn delete 可以对目录进行操作, 就像它们操作普通文件那样, svn copy 和 svn move 同样如此. 但是这些 命令 不会 导致仓库马上被修改, 项目的添加或删除 只是被排到了日程表中, 只有在执行完 svn commit 后, 仓库才会发生变化.
目录不再是一个哑容器, 它和文件一样具有版本号. (因此我们可以
放心地说 “在版本号为 5 时, 目录 foo/
.
”)
关于最后一点我们再多说一些. 对目录进行版本控制是一件很麻烦的 事, 因为我们希望工作副本能够支持混合的版本号, 这就使得我们在对目录 进行版本控制时有些限制需要遵循.
从理论上讲, 我们把 “目录 foo
的版本号
5” 的涵义定义成目录项和属性的特定集合. 现在假设我们从目录
foo
里添加并删除了一些文件, 然后提交, 这时候
如果再说 “我们仍然拥有目录 foo
的版本号 5” 是不对的. 再者, 如果我们在提交后更新了目录 (仅
目录) foo
的版本号, 这时候再说 “我们
仍然拥有目录 foo
的版本号 5” 还是不对,
因为目录中可能还有其他一些文件的更新还没有收到.
Subversion 解决该问题的方法是在目录 .svn
内
安静地跟踪已提交的添加和删除. 当用户最终执行 svn
update
时, 所有的信息都将与仓库同步, 目录的新版本号也
会被正确地设置. 因此, 只有在更新后才能放心地说你已经拥有了
一个具有 “完美” 版本号的目录. 在大多数时候,
你的工作目录总是存在 “不完美” 的目录版本号.
类似的, 当你试图提交目录的属性修改时可能会引起另一个问题. 通常情况 下, 提交操作将会更新目录的本地版本号, 但这仍然是在撒谎, 因为还未执行更新 操作, 因此可能存在目录项的添加和删除未在目录中体现出来. 因此, 只有在目录完全更新之后, 你才能提交目录的属性修改.
关于对目录进行版本控制而产生的限制, 其更详细的讨论见 “版本号混合的工作副本”一节.