Subversion实践案例——客户现场模式的分布式开发

基本信息
用户单位：某应用软件研发企业
用户规模：100人以上
组织过程水平：中等
CMMI评审等级：无
Subversion使用时间：1年
客户需求
由于公司每次向新客户提交软件的时候都需要派出一个小规模的团队到客户现场进行一段时间的软件定制和维护。此外，老客户系统的重大升级和功能扩展也需要一个小团队在客户现场进行一段时间的开发。因此，异地开发的配置管理就是一个比较突出的问题了。
虽然SVN本身提供了通过Http协议进行远程访问的能力，但出于安全的考虑，作为存有公司核心资产（源代码）的配置库在物理上和外部公共网络是相隔离的，所以必须采用分布式的管理模式。相关的具体需求可以归纳为：
1、需要从主配置库中分离部分内容创建用于在异地开发的远程配置库
2、远程配置库的访问权限能够直接从主配置库中直接获取
3、可以对远程配置库进行单独的授权控制和管理
4、当派出团队回到公司总部时需要对两个配置库的内容进行同步
5、派出团队在异地时也需要用非在线的方式（如邮件、即时通信工具、FTP等）对两个配置库进行数据的同步。
问题解析
    Subversion作为一种集中式管理的版本管理系统，本身并不支持分布式的开发管理，所以需要一些额外的技术手段。目前唯一支持SVN的分布式版本管理系统是SVK——一款基于脚本实现的开源软件。但该软件除了在使用上较为繁琐外，并不能满足用户对访问控制及离线同步等方面的要求。
    同时，根据分布式开发模式的特点，适合采用“远程代码线”的分支结构模式。因此，最为可行的解决方案应该是在“远程代码线”的模式的基础上通过技术上的一定扩展从而实现用户的所有相关需求。
我们的解决方案
我们所提供的解决方案如下图所示：



    首先，在主版本库中采用远程代码线的分支结构模式，并通过远程代码线创建客户现场所使用的远程版本库，然后通过在线和离线两种方式进行数据的同步。 
    在这种操作模式下，为了保证数据的完整性和一致性，我们采用了若干技术手段提供了如下的约束机制：
    a、主版本库中的远程代码线在下一次同步操作前一直处于冻结状态，不允许进行任何检入操作。
    b、远程版本库中的主代码线、主版本库中的远程代码线以及主版本库中的主代码线三者的同步必须按照一定的顺序完成一个周期（如上图所示）
   另外，通过建立远程开发团队的相关信息，在创建远程版本库的时候，将继承主版本库的团队成员相关的访问控制权限，并提供对远程版本库的访问控制进行单独定义的机制。
参见：SmartChange分布式开发管理模块