从ClearCase到TortoiseSVN
习惯了使用ClearCase之后，原本以为转换到SVN会有很大的不方便。没想到TortoiseSVN带给我的却是比ClearCase更灵活的功能。感觉SVN的概念大部分来自于ClearCase，却又完全抛弃了ClearCase中的许多冗余繁杂的功能。可以说SVN真是轻装上阵，身手敏捷。
我现在还只是在本机上安装了SVN，平常的工作也只是自己一个人的代码Check in/out（相当于SVN的Commit概念），所以我暂时还不能说SVN得功能比ClearCase强大。就讲讲SVN怎么个灵活法吧。
先略略带过几个代码管理的基本概念，我认为要想快速上手并且合理有效的使用SVN、ClearCase，这些概念很重要。首先是“代码库”的概念。讲一句废话，同一个代码库中可以存放多套产品代码。在ClearCase中，一般采用不同的VOB来划分不同的产品代码，在SVN中相对比较简单，在Deposit的根目录下创建不同的子目录就可以。
再讲讲“分支Branch”和“标签(Tag/SVN，Label/ClearCase)”。在ClearCase中，两个概念是划分的很清晰的，拿棵树打个比方，要创建一个Branch，就在主干分支或其他分支上拉出新的分支；而打标签就是选定一个平面，给其中的每个代码文件的选定版本打上一个标签。
而在SVN中，由于采用了“镜像Copy”机制，创建分支和创建标签的操作方法是一样的，无非都是选定一个目录，然后执行“Copy to”操作，新创建的目录就是你所创建的分支或标签。正因如此，SVN才会需要推荐代码库的目录结构，使用Trunk、Branches和Tags三者分别表示主干分支、子分支和标签。
如果没有使用过ClearCase或其他版本控制工具，那么在使用SVN之前，需要尽量理解标签和分支的不同作用。不要把“分支”的概念混淆于磁盘上的“目录”（或“文件夹”）。
对于一套产品代码，设定了目录结构之后，我们一般将其确定为主干分支，例如对于Project1，主干分支的目录应该是file:///D:/deposit/Project1/trunk。ClearCase的使用者们一般习惯在为一套产品代码创建主干分支（ClearCase中即是MAIN）后，为每个不同子版本建立各自的主干分支，例如/MAIN/VER_1_0_MAIN、/MAIN/VER_2_0_MAIN。在SVN中大可不必这么做，这里先不讨论。
确定了主干分支后，我们一般定义一个子分支用于日常的开发，在其上进行Check Out/Check-in|Commit代码等操作。在发布（Release）版本的时候，先在子分支上Commit所有代码，然后Merge到主干分支，打上标签，然后开始出版本。所以我们一般在本地磁盘上会从主干分支和子分支各Check-Out一套代码，一套用于开发，一套用于Release。
然后就是从代码库中取出代码。
使用ClearCase就必须了解它的“Config Spec”。Config Spec实在是太强大了，一个复杂的Config Spec可以灵活的从不同VOB、不同代码目录、不同代码分支和不同代码标签获取到你想要的一套代码。所以使用ClearCase的方式一般是，确定VOB，找到VOB中的目录，然后确定一个分支，然后从该分支上的某一个标签或LATEST位置获取代码。
对于SVN，我还不知道是否有类似的功能，目前我只是使用最简单的操作：从Deposit Browser上选择一个开发分支所在的根目录，然后将其Check-Out到磁盘上保存本地代码的路径，仅此而已，不需要考虑不同的目录结构、不同的分支，或是不同的标签。这正是SVN与ClearCase的一个很大的不同，SVN的版本控制策略非常简单，但是足够应付大部分情况。至于其他情况，完全可以通过简单的Windows文件夹管理方法解决。例如如果两个项目共享一个目录，在ClearCase中Config Spec就可以大显身手了，而在SVN中，只需要在Check-Out的时候为共享目录和项目主目录分别创建代码目录就可以了。
在ClearCase中，需要首先创建一个View来取出代码，创建了View之后才能够执行Check-Out、Check-In等操作。而在SVN中的Check-Out操作本身就创建了一套本地代码。
SVN还有的一个简便之处在于，如果是同一份代码的两个目录，其中一个失从SVN Deposit中check-out的，另一个不是，那么只要拷贝“.SVN”文件夹到另外一个代码目录，那么立刻可以使其成为受管辖的代码目录。虽然这个功能似乎很无稽，但是确实对于一些情况很方便。如果你知道ClearCase管理它的View的复杂方法，你就知道SVN在这一点上多么人性化。
Posts
