周五解决了部门SVN的一个需求，大概在这里描述一下。
SVN是我来到这个部门之后由我来搭建并推广的（说实话，我之前），鉴于这个部门之前用VSS和拉代码的历史，目前SVN的现状是这样的：
一、以一个SVN库的结构为例，大概代码架构示意图如下。
-------BASE/alps(基线版本，由平台负责人负责维护)
--- Branch(基线分支1，由平台负责人负责维护)
--- Branch(基线分支2，由平台负责人负责维护)
--- Branch(基线分支3，由平台负责人负责维护)
-------Project1（项目分支1，包含整份MP的代码，单列编译，由项目负责人负责维护)
-------Project2（项目分支2，包含整份MP的代码，单列编译，由项目负责人负责维护)
-------Project3（项目分支3，只包含几个差异的文件，覆盖编译，由项目负责人负责维护)
-------Project4（项目分支4，只包含几个差异的文件，覆盖编译，由项目负责人负责维护)
...........
-------Project20（项目分支20，只包含几个差异的文件，覆盖编译，由项目负责人负责维护)
Project有的是单列的，尤其是项目量产之后，为了保持项目稳定，就单列出来了，整个目录就是一份完整可以编译通过的工程。
有些是项目早期，目录里只有一些配置文件或者有特色的差异文件，编译项目工程的时候，是先取出基线版本 + 基线分支 + 项目分支这样依次取下覆盖，然后得到一份完整的工程来编译的。这样的好处是，可以用到基线版本的修改。
二、问题描述
代码总有打一些Patch的，一般总是合入在基线版本里，对于那些单列的项目，平台更新了重要Patch，就算邮件群发通知了，可能各项目负责人也不一定能及时更新。所以，得想出来一个办法，看“能不能让基线维护人员在modem patch更新后把本基线下所有单拉分支都给锁上（不能上传也不能下载）“。
三、问题解决
1、能不能让基线维护人员在modem patch更新后把本基线下所有单拉分支都给锁上（不能上传也不能下载）
——
（1）我没能找到有这样的一条svn命令；想到的方法只能是可以在SVN服务器侧设置权限为No Access，这样没人能访问了，但感觉这样做不太好。而且要逐一修改各个单拉分支，也很麻烦。
（2）又想了个方案：
在base下写个文件，叫basever，里面记录基线modem的最新版本号或者日期，比如V09或者20120511，这个由基线维护人员来维护，每次打modem patch之后修改。
在各分支根目录下也有一个文件叫subver，里面记录分支modem的最新版本号或者日期，比如V01或者20120101，这个文件由各分支版本人员来维护，每次同步基板modem patch之后修改。
由于basever和subver两个文件的文件名不一样，所以文件不会被覆盖。拉下代码后，每次new的时候会检查此文件内容是否一致，如果版本号不一致，new的时候一开始就立即编译不过去的。这个时候编译的人就知道要联系SPM或者RF修改modem了。
目前此方案我已做好并自测OK（见文件附件cehckver.rar，放到版本根目录下即可），如果觉得可行的话，可以考虑在ICS、6577等平台实施。
（2）对于一些单拉的项目，可以写脚本单独取一下Base里的basever文件，然后进行比较即可。
（3）继续思路扩展（目前还没做，不过也不难，先看方案是否可行）：
对于一些早已单拉的项目，用来进行一些重大问题Patch的更新。
在basever和subwen文件里也加入Patch控制，比如文件内容可以如下：
modemver = Modem_V1_P2
MPatch = [P01,P02,P03] #系统强制性的Patch，比如一些重大问题
OPatch = {P04} #可选的Patch
TPaach = [T01,T02] #临时Patch
#P1 Patch描述，大概修改文件，修改人，日期
#P2 Patch描述，大概修改文件，修改人，日期
#P3 Patch描述，大概修改文件，修改人，日期
#P4 Patch描述，大概修改文件，修改人，日期
#P5 Patch描述，大概修改文件，修改人，日期
#P6 Patch描述，大概修改文件，修改人，日期
单拉项目比较强制性的Patch，如果单拉的Patch没有合入的话，则编译不通过！
四、结果
经开会讨论，下周先在ICS平台上试点实施。
...