本节和大家一起学习一下SVN文档的要点，在学习SVN的过程中你可能会遇到SVN问题，于是和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，欢迎打击一起来学习SVN文档方面的知识。
1.Subversion可以告诉我们工作文件是处于如下四种状态的那一种：
SVN文档未修改且是当前的
文件在工作目录里没有修改，在工作修订版本之后没有修改提交到版本库。svncommit操作不做任何事情，svnupdate不做任何事情。
本地已修改且是当前的
在工作目录已经修改，从基本修订版本之后没有修改提交到版本库。本地修改没有提交，因此svncommit会成功提交，svnupdate不做任何事情。
SVN文档未修改且不是当前的了
这个文件在工作目录没有修改，但在版本库中已经修改了。这个文件最终将更新到***版本，成为当时的公共修订版本。svncommit不做任何事情，svnupdate将会取得***的版本到工作拷贝。
SVN文档本地已修改且不是***的
这个文件在工作目录和版本库都得到修改。一个svncommit将会失败，这个文件必须首先更新，svnupdate命令会合并公共和本地修改，如果Subversion不可以自动完成，将会让用户解决冲突。
这看起来需要记录很多事情，但是svnstatus命令可以告诉你工作拷贝中文件的状态，关于此命令更多的信息，请看“查看你的修改概况”一节
2.混合修订版本的工作拷贝
作为一个普遍原理，Subversion努力做到尽可能的灵活，一个特殊的灵活特性就是让工作拷贝包含不同工作修订版本的文件和目录，不幸的是，这个灵活性会让许多新用户感到迷惑。如果上一个混合修订版本的例子让你感到困惑，这里是一个为何有这种特性和如何利用这个特性的基础介绍。
SVN文档更新和提交是分开的
Subversion有一个基本原则就是一个“推”动作不会导致“拉”，反之亦然，因为你准备好了提交你的修改并不意味着你已经准备好了从其他人那里接受修改。如果你的新的修改还在进行，svnupdate将会优雅的合并版本库的修改到你的工作拷贝，而不会强迫将修改发布。
这个规则的主要副作用就是工作拷贝需要记录额外的信息来追踪混合修订版本，并且也需要能容忍这种混合，当目录本身也是版本化的时候情况更加复杂。
举个例子，假定你有一个工作拷贝，修订版本号是10。你修改了foo.html，然后执行svncommit，在版本库里创建了修订版本15。当成功提交之后，许多用户希望工作拷贝完全变成修订版本15，但是事实并非如此。修订版本从10到15会发生任何修改，可是客户端在运行svnupdate之前不知道版本库发生了怎样的改变，svncommit不会拖出任何新的修改。另一方面，如果svncommit会自动下载***的修改，可以使得整个工作拷贝成为修订版本15—但是，那样我们会打破“push”和“pull”完全分开的原则。因此，Subversion客户端最安全的方式是标记一个文件—foo.html—为修订版本15，工作拷贝余下的部分还是修订版本10。只有运行svnupdate才会下载***的修改，整个工作拷贝被标记为修订版本15。本节关于SVN文档方面的知识讲解完毕。
【编辑推荐】
