svn到git的迁移与过渡方案
发布： 2013-12-25 10:51

svn与git都是源代码版本控制软件，但它们属于不同的时候。
svn特点在集中式的管理方式，而git更适合于当前分布式管理方式。
当前从svn到git的迁移方案，都是以git为目标，从git的角度提供了相对的迁移策略。
使用的比较多的是，git-svn 和 subgit。

前者出现的早，一直是在git包里自带，用的人多些，在最新的版本里对分支的支持已经非常完善了。
但是它只是一个客户端口的解决方案，能让使用人员用git的方式管理svn代码库，并最终把代码存储在服务器的svn服务器上。
后者属于第三方的解决方案，并且是个商业产品。客户端的使用纯git命令而非git-svn命令，
并在git服务器上提供服务器端的配置支持，让服务器上的git与svn服务器保持同步。

在客户端上则看不到svn的影子，只是把git-svn拿到服务器上使用，并且自动化了。

这两种方案最终都是使用 git或者类似git命令管理代码，与向git的迁移目标一致。

前者在本地的所有管理命令使用git命令，最终提交到远程svn库。
svn服务端无需要任务改动，只是客户端使用git-svn命令。
目前来说，git-svn对svn的分支与tag支持已经非常好了，对svn的子目录支持也非常好了。
但是这种方式，最好还是意向操作，即以svn为主版本存储，
所有的提交要么以svn客户端命令直接提交到svn中，
要么使用git-svn命令提交到svn中，
然后再使用git-svn命令同步到服务器上的git库中。
如果这时候，即有使用git提交到服务器上的git库中，又有使用svn提交到svn库中，
当两者有冲突的时候，则非常难处理了。
假如希望完全使用git命令，那么，这个git库对应的svn目录就不能再直接提交了，
而是只能允许一个从git库到svn库的后台自动提交，这个过程由git库的钩子程序执行。
也就是要么屏蔽掉svn库某个对应目录的提交，要么屏蔽掉git库对应库的提交，
总之他们只能实现单向的用户，而无法或者很难实现两边同时提交，并且不能保证双向的代码库自动完全同步。
这个时候，我们需要一个放在服务器上的自动处理svn与git库同步的工具，
我把这个称作gitsvn_bridge，而这个工具应该与subgit提供的工具类似。
自行设计的这个gitsvn_bridge与subgit的服务器端机制，都是通过相应的版本库提交事件钩子程序，
触发这个连接器执行相应的代码同步逻辑。
这个的实现会在下一篇中详细说明。


原文： http://qtchina.tk/?q=node/779

Powered by zexport