• revert操作：将现在工作空间的所有修改都删除，恢复到工作空间所在版本的服务器端文件。以前一直认为revert是用来回溯版本的，其实不是。
• update to version操作：这个才是真正用来回溯版本的。而且，在回溯的时候，工作空间所有的修改都不会被删除，而是会进行合并。所以如果有修改的话，在回溯时，可能会有冲突。

SVN命令行

常用命令使用说明：svn command

SVN工作实例

什么时候会产生冲突（conflict）呢？ 这个必须从svn update操作说起。下面是一个使用svn工作的实例。

• svn checkout

获得三个文件及其版本号（svn上和本地）

a.c	1
b.c	1
c.c	1

• 本地修改了文件b.c和c.c

此时，文件a.c和b.c都被人修改了，并且上传到svn上，svn上对应的版本号如下

a.c	2
b.c	2
c.c	1

• svn update

第二天你需要继续在b.c和c.c上进行工作，但是你担心昨天自己不关心的文件a.c被修改了，所以你开始今天工作之前做的第一件事情就是svn update。将你现在本地的文件和svn上的文件保持一致。

第二种情况就是你需要将修改的文件b.c和c.c上传，但这两个文件可能已经被别人修改并且上传到svn版本库中。这个时候，你需要svn update。

svn update的结果就是： 本地文件：

a.c	2	（由于本地的版本1没有修改，该文件自动跟新为svn上的版本2的文件）
b.c	conflict or merge
c.c	1	（本地版本和svn上的版本保持一致，为1。只是你在版本1上做的修改尚未上传）

关于b.c文件中conflict和merge的说明

本地的版本1被修改，而svn上的版本2也是从版本1修改而来的，如果现在本地修改的b.c和svn上的版本2有不相同――一般都会有不相同的，就会产生合并或者冲突。那么，什么是合并，又什么是冲突呢？什么时候会产生合并，什么时候会产生冲突呢？其实，SVN是以行为单位进行比对的。如果现在本地的b.c和SVN上的b.c文件（已经是版本2）对同一行进行了修改（做了修改使相对于版本1），那么，就会产生冲突，如果不是对同一行进行了修改，那么就会合并所作修改的行。解决冲突的过程，就相当于在版本2的基础上做修改，冲突解决完成，则本地的b.c文件的版本号变为2，只是你还是在版本2的基础上有修改而尚未上传。

• svn commit

进过第三步之后，你软件版本已经和svn上的保持一致了，你现在就可以在最新的软件版本上工作了，当然，你也可以上传代码到svn。使用svn commit。

如何使用SVN查看代码的变化 情况一：在update一个文件的时候，文件被合并（merged）。这个时候，你可能想看两方面的变化：

• 自己做了哪些修改

compare with working copy 这会拿svn上的最新版本和本地的文档进行对比。注意，此时本地的文档已经是上一版本做的修改和svn上的最新版本的合并（merged）的一个文件。所以，比较看到的就只有自己做的修改部分。

• svn上的版本做了哪些修改

compare with previous revision 这会拿svn上的最新版本和svn上的上一版本进行对比。由于svn上的最新版本已经合并到本地文件中，这样就可以看到svn上的版本（其实也就是本地合并版本）相对上一版本被别人做了哪些修改。

Git does a simple three-way merge:

• Snapshot to Merge Into
• Snapshot to Merge In
• Common Ancestor

对于SVN（早期版本），则需要自己选定一个best merge base（Common Ancestor）。

This is a special case of the tree merge described below, and it requires only the URL to merge from (normally) your development branch. It uses the merge-tracking features of Subversion to calculate the correct revision ranges to use

merge tracking features of Subversion

产品线svn

在讨论产品线软件版本管理的时候，提出的一个管理模型一个分支模型。

下图为产品线软件版本svn图（图片为wmf格式，web下暂时无法显示）。