Subversion学习笔记3

经过一段时间实际使用SVN来管理手头的实验性项目，遇到和解决了一些实际问题，所以再做个笔记。

上一篇笔记中纪录了我将一些项目编译产物用svn:ignore属性来忽略对他们的版本控制。后来我发现svn:ignore属性也能用来忽略文件夹，只要用文件夹名就不会对文件夹进行版本控制了，呵呵。所以我便将bin，testresult等Visual Studio存放代码产物的目录设置成忽略，这些空的文件夹就不会出现在代码仓库中了。

今天喳喳跟我要MaxLab.Common.Data的最新代码。他想在新版本的bbsMax的转换器中使用。因为考虑到两个项目是异步进行的，可能bbsMax的转换器使用我给的代码时发现一些bug，而我在自己的源码管理器中又把项目的代码改得面目全非和原先给喳喳鸟的代码完全不一样，这样我变得不好对bug修复进行版本控制。所以我决定先发布一个小版本给他先用。

发布版本时原先代码仓库组织的上的问题就暴露出来了。我用TortoiseSVN创建了一个MaxLab.Common.Data/trunk目录的版本分支到MxLab.Common.Data/branches目录中，名为0.5.1。同步我本地的代码后，发现分支会把trunk目录和子目录的所有属性等原样复制。这样，0.5.1目录下的MaxLab.Common目录也是用svn:externals从MaxLab.Common项目的trunk目录共享来的。这样如果MaxLab.Common项目以后在开发时变更了trunk中的代码和文件(这是非常可能的，因为trunk是项目主干)，我做的MaxLab.Common.Data项目的0.5.0分支就费了。

还好及时发现这个情况。我想了一下，觉得项目之间如果要做svn:externals的代码共享，最好共享代码的来源要在为发布创建的版本分支或者tag下，这样才能比较好保证代码的稳定性，不至于一个项目修改了主干代码，别的项目的版本分支就不能编译了。

包括vendor目录也是，里面的第三方组件也可能存在版本问题，如果放在和trunk同一级，就不好一起打tag或做版本分支。所以vendor目录我移到了trunk目录下级。并先对MaxLab.Common项目做了一个0.1.0的tag到tags目录下，然后把MaxLab.Common.Data的trunk目录中对MaxLab.Common项目主干的引用改为对0.1.0的tag的引用。然后再做MaxLab.Common.Data项目的0.5.5版本的tag到tags目录下。

其实这个问题折腾了有一会儿，也不止折腾一次，所以MaxLab.Common.Data项目版本才会变成0.5.5，呵呵。并且我决定把为发布做的版本分支放到tags目录下，而branches目录用来存放功能上的版本分支。

整理完后的项目结构示意图：