【版本控制管理】SVN常见难点记录

知识点一：

1、svn上有主干trunk和日常分支rcrw20161104，有一个文件a.java原始修改时间为9.22。

现做如下操作：

（1）11月7日修改主干trunk的a.java文件，将参数606修改为618。

（2）11月8日修改分支rcrw20161104的a.java文件，将参数606修改为618。

（3）11月9日再次修改分支，将a.java回退到修改前版本，即将618修改为606。

（4）将分支合并到trunk上，发现a.java以trunk上的代码为准，参数为618。

原因：第一次提交，再回退以后，SVN产生两个版本号，但是svn认为你是未做任何修改的。

而trunk在11月7日做了修改，合并后就以trunk为准。

注：需要深入了解一下SVN的合代码的比较原理。

知识点二：

0:SVN的版本号是怎么回事？

    svn commit 操作可以作为一个原子事务操作发布任意数量文件和目录的修改。在你的工作副本中，你可以改变文件内容，创建、删除、改名和复制文件和目录，然后作为一个整体提交。

    在版本库中，每次提交被当作一次原子事务操作: 要么所有的改变发生，要么都不发生，Subversion 努力保持原子性以应对程序错误、系统错误、网络问题和其他用户行为。每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做版本，每个版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是 0，只创建了一个空目录，没有任何内容。

    可以形象的把版本库看作一系列树，想象有一组版本号，从 0 开始，从左到右，每一个修订号有一个目录树挂在它下面，每一个树好像是一次提交后的版本库“快照”。

不像其它版本控制系统，Subversion 的版本号是针对整个目录树的，而不是单个文件。每一个版本号代表了一次提交后版本库整个目录树的特定状态，另一种理解是版本 N 代表版本库已经经过了 N 次提交。当 Subversion 用户讨论“foo.c的版本 5”时，他们的实际意思是“在版本 5 时的foo.c”。需要注意的是，一个文件的版本 N 和 M 并不表示它必定不同。

   需要特别注意的是，工作副本并不一定对应版本库中的单一版本，他们可能包含多个版本的文件。举个例子，你从版本库检出一个工作副本，最新的版本是 4:

calc/Makefile:4     integer.c:4     button.c:4

   此刻，工作目录与版本库的版本 4 完全对应，然而，你修改了 button.c 并且提交之后，假设没有别的提交出现，你的提交会在版本库建立版本 5，你的工作副本会是这个样子的:

calc/Makefile:4     integer.c:4     button.c:5

   假设此刻，Sally 提交了对 integer.c 的修改，建立修订版本 6，如果你使用 svn update 来更新你的工作副本，你会看到:

calc/Makefile:6     integer.c:6     button.c:6

   Sally 对 integer.c 的改变会出现在你的工作副本，你对 button.c 的改变还在，在这个例子里，Makefile 在 4、5、6 版本都是一样的，但是 Subversion 会把 Makefile 的版本设为 6 来表明它是最新的，所以你在工作副本顶级目录作一次干净的更新，会使所有内容对应版本库的同一修订版本。