进城务工人员小梅系列文章：
对于标准的SVN代码仓库，可以直接使用Bitbucket的SVM Mirror实现SVN与GIT的双向自动镜像，使得项目开发人员可以同时使用SVN和GIT对原SVN仓库进行操作。这样，可以减轻项目组切换到GIT上时的痛苦程度，给予充分的缓冲空间并逐步迁移到以Bitbucket为核心的代码管理机制上。
一、在Repo中配置SVN Mirror
主要配置：
- SVN地址
- 使用的SVN用户名密码
- 分支及Tag映射方式
- 在Bitbucket中找不到SVN用户名如何补后缀
请注意，分支及Tag映射方式是最为重要的，只有能够通过映射的方式映射SVN与GIT分支时才能正常实现在双向同步。
在实践中发现，各个项目组管理SVN分支的方式千奇百怪，基本都不是标准的SVN工程结构，因此在本文最后有几个实际工程的映射方法作为示例。
二、导入
首次时，需要通过Import将SVN导入到Git中。注意：此动作只能进行一次，如果工程结构映射不正确，则只能删掉Repo后重新建一个。
导入过程是由Bitbucket自己调度的，对于大的SVN仓库需要很久，请耐心等待。
开始导入：
三、开启同步
SVN导入完成后，同步会被关闭，需要手工开启：
四、非标准SVN工程结构映射方式示例（一）
以下是一个在trunk中混入了两个工程的示例：
当想在Bitbucket中只关注*-parent项目时，可以如下建立映射，只匹配该工程相关的主干、分支及标签：
五、非标准SVN工程结构映射方式示例（二）
以下是一个分支不以branches、标签不以tags为文件夹的示例：
可以如下建立映射：
请注意：千万不要试图在SVN中将branch重命名为branches来解决问题，这样会导致在import时丢失分支上提交记录（实际是import时不会导入move/copy之前的SVN提交记录，当然提交记录还在SVN上，怀疑是Bitbucket低版本的BUG）。
请注意：若为SVN标准代码仓库（branches、tags），则可以用前缀路径区分；若非SVN标准代码仓库，对于当前的Bitbucket而言，即使使用SVM Mirror进行了映射且可以正常import，如果分支名称带有前缀那么也无法从Git同步到SVN，怀疑是Bitbucket低版本的BUG。因此，建议不使用前缀而使用扁平的结构。
六、非标准SVN工程结构映射方式示例（三）
以下是一个分支不以branches、标签不以tags为文件夹，且主干与开发分支分散到不同SVN路径中的示例：
该项目组的分支管理粒度很粗，而且生产和开发的分支位于不同的SVN路径中，由于Mirror时的映射关系是相对于SVN路径的，因此无法简单地、在保留提交记录的情况下实现双向同步，需要参考《SVN2GIT之路（二）SVN到Git的手工迁移（保留所有分支、Tag及提交记录）》中的方法手工迁移。以下的例子只同步了主干，可以将其他分支挪到Git工程中。
转载时请保留出处，违法转载追究到底：进城务工人员小梅 » SVN2GIT之路（三）SVN与GIT的双向自动镜像