SVN切换到Git方法及坑点

腾讯工蜂Git:基于Git的企业级协作开发解决方案,腾讯未来研发关键系统 https://code.tencent.com

腾讯工蜂用户:张宁浩

背景:

SVN和Git同样都是在特定时代下比较优秀的版本控制系统,但是随着时代的发展,SVN越来越不能满足多人开发的需求,尤其是在多种多样,天马星空的业务场景面前,SVN会显得力不从心,而Git也慢慢的成为趋势。

最近在将公司的项目从SVN迁移到git,踩了不少坑,所以来记录下:

因为迁移的快慢和整个仓库的大小,电脑配置有关,所以我先说下这边的情况

  • 仓库: 仓库大概是3.5G左右,包含了14500+的提交次数,其中包含了超过500M的单个文件
  • 电脑: 电脑配置就看图吧 :

在以上两种情况下,排除掉采坑的时间,总耗时在10小时左右,当时中途我也用过一台联系X1的本尝试过,配置如下:

后来联想这台电脑放弃了,因为总耗时已经超过30小时,

操作:

生成作者文件:

因为我们知道,在SVN上提交和在Git上提交对应提交者的信息展示是不同的,SVN只会保存一个用户名,而Git会保存该用户的邮箱,所以我们迁移的第一步就要生成一个映射文件,将SVN上的用户名和其邮箱对应起来,就比如 molier = molier <123456@qq.com>,转换的办法有很多,如果你团队里面的人不是很多的是时候,可以自己去提交记录中手动生成这样一个TXT文件

XXX = XXX <XXX@XXX.com>XXX = XXX <XXX@XXX.com>....

但是如果,多人开发人数很多的时候,手动转很累,我们就需要一个Atlassian的工具包 svn-migration-scripts.jar,通过命令拉取SVN仓库的用户并生成对应的开发者信息映射文件,需要Java运行时环境支持,大家可能还需要安装JDK:

java -jar svn-migration-scripts.jar authors https://svn.example.com > authors.txt

这样之后会在当前目录生成一个 authors.txt 文件

转换仓库

整体转换

标准的SVN文件布局: 如果SVN仓库使用标准的了/trunk, /branches和/tags的目录结构,就可在运行命令时加上参数–stdlayout,使用如下命令

git svn clone --stdlayout --authors-file=authors.txt <svn-repo>/<project> <克隆到文件夹的名字>非标准的的SVN文件布局:

如果SVN仓库是非标准的目录布局,那就需要分别显示指定参数–trunk, –branches, –tags。

git svn clone --trunk=/trunk --branches=/branches --branches=/bugfixes --tags=/tags --authors-file=authors.txt <svn-repo>/<project><克隆到文件夹的名字>

部分转换

如果仓库非常庞大的话可以选择部分转换,也就只转换指定提交之后的提交,可以试用如下代码

git svn clone -r123456:HEAD --stdlayout --authors-file=authors.txt <svn-repo> <克隆到文件夹的名字>

不过这里需要注意的是如果使用这种方式来转换那么一定要指定SVN的代码根部,而不能指定分支,因为SVN的提交编号都是按照时间顺序来往下依次排列,不同的分支也可能提交编号是连续的,所以如果只关心编号的话就不能再指定分支了。

以上三步中所用到的 authors.txt 即为上一步所生成的,作者 -> 作者 <作者邮箱> 的对应关系文件.

坑点

完成以上操作的话如果一切正常那么你就会获得一个新的Git仓库,然后就可以添加到远端,进行多人开发了,至于git的操作并不在本文的范围内,下面会讲一下遇到的坑以及解决办法。

坑点一:时间久

转换仓库是比较耗时的,因为他会一个提交一个提交的转换,转换的速度和你的仓库提交次数和电脑配置成正比,我当时转了十几个小时比较正常,而且转换完之后他还有个自己整理文件的过程也是很耗时的,不过如果你选择部分转换的话也可能很快,假如你一共15000个提交,然后你从14999来转换可能几分钟就够了。当然最好的办法就是下班前开始执行,第二天来了基本就差不多了。不过别高兴的太早,请看坑点二。

坑点二:垃圾过多导致暂停

因为是要遍历所有的历史提交,所以可能会有很多的无用文件 比如项目一开始代文件结构很乱,然后慢慢的经过重构,之类的优化步入正轨,这过程中必然会删掉大量的无用、冗余的文件,虽然这些文件已经不复存在了,但是提交记录会有,而且通过git的原理来看他还是会把这些东西一一保存下来,所以就会造成大量无用的文件越来越多,而Git是有一个缓冲区(具体大小不确定)当你无用文件把缓冲区沾满了,那么转换过程会停止会爆出如下错误

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.error: The last gc run reported the following. 
Please correct the root cause and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.
warning: There are too many unreachable loose objects; 
run 'git prune' to remove them.gc --auto: command returned error: 255

大概意思是垃圾太多,转移暂停让你先清理垃圾,其实只要按照他说的 进到我们转了一半的仓库 进行 git gc 就可以,但是这样一来我们就需要一直守在电脑前,随时准备输入 git gc 而且假如你下班前开始跑结果第二天上班一看跑到一半就暂停了,白白浪费了一晚上的时间,真的会崩溃的。所以通过google找到了解决办法

也就是开始转换的时候先进入仓库输入 git config gc.auto 0 关闭gc功能,然后就可以一直跑到黑了,你大可以放心的运行命令然后下班回家。不过还有一点需要注意的是垃圾文件是否过多和你仓库大小没有太大关系,及时你仓库提交不多,但是每次提交都有很大改动的话也还是会出现这个问题,所以这里建议不管你仓库多大,都要先进行一下这个操作,以防万一。

坑点三:大文件处理

git和SVN不同,在git上提交的单个文件是有大小限制的,超过这个大小就不允许提交到仓库中,通常我们会用git LFS来解决,具体的安装,添加步骤网上大把的教程,就不在这里说,不过他只会告诉你大文件的大小和限制的大小,具体的大文件是哪个他不会告诉你,这里可以用以下命令查看

git ls-tree -r -t -l --full-name HEAD | sort -n -k 4 | tail -n 10 //查找git 仓库中排名前十的大文件(升序)

他会输出前十个最大的文件,然后你再按需处理。但是当你把大文件添加到LFS中后再次推送还是会爆出同样的错误,而且还是同样的文件,也就是说你根本没添加成功,其实并不是这样的,在添加LFS中只要你操作没错,就是添加成功了,他还会报错的原因是因为虽然你工程中的大文件已经添加,但是你的历史提交记录中是包含大文件的代码快照的,所以你需要将历史上所有包含大文件的提交记录重写,删掉大文件相关的东西,git 中重写commit的命令是:

git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch 你大文件所在的目录' --prune-empty --tag-name-filter cat -- --all

这个过程也比较漫长,他会便利你所有的提交记录并一一修改,不过就是漫长的等待就可以了,等到完成之后我们需要将代码push到远端,因为我们修改了所有的commit 我们需要强制push使用如下命令

git push origin master --force

坑点四: 打包时间过长

再上一步我们执行完推送命令的时候,会先进行文件打包处理,这个过程也是非常漫长,而且非常消耗电脑资源的,按照我的电脑配置来说,这个过程一旦开始,电脑基本就是内存、cpu全满的状态,鼠标也没法动,所以这个过程要有心理准备。漫长的等待之后就推送成功了。


扫描以下二维码,研发管理从此高效、轻便、可靠

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Android-JessYan

MVPArms官方首发一键生成组件化,体验纯傻瓜式组件化开发

原文地址: https://www.jianshu.com/p/2452ea776a45

30130
来自专栏北京马哥教育

Linux 软中断机制分析

软中断分析最近工作繁忙,没有时间总结内核相关的一些东西。上次更新博客到了linux内核中断子系统。这次总结一下软中断,也就是softirq。之后还会总结一些ta...

62880
来自专栏开源优测

[快学Python3]浏览Python Manuals

概述 通常情况下,初学者都不愿意直接去浏览Python Manuals,即Python自带的官方文档。尤其是只有英文版的情况下,初学者更加不会去使用该官方文档了...

28990
来自专栏北京马哥教育

Linux内存被吃掉了,它去哪里了?

在Windows下资源管理器查看内存使用的情况,如果使用率达到80%以上,再运行大程序就能感觉到系统不流畅了,因为在内存紧缺的情况下使用交换分区,频繁地从磁盘上...

15430
来自专栏达观数据

达观数据基于RequireJS的前端模块化设计

伴随着互联网的飞速发展,web中对于前端的要求越来越高,前端的代码的代码量、复杂度与日俱增,带来了诸如前端代码复用率低,难维护等问题。针对这些现有问题,达观科技...

28650
来自专栏IT可乐

Linux系列教程(三)——Linux学习技巧

  前面我们讲了Linux系统的详细安装教程,大家跟着教程一步一步的操作,应该能完美的完成安装。那么这篇博客跟大家聊聊如何来学习Linux。 1、工欲善其事必先...

28770
来自专栏Java帮帮-微信公众号-技术文章全总结

day28.Redis【Python教程】

下载:打开redis官方网站 https://redis.io/,推荐下载稳定版本(stable)

8510
来自专栏做全栈攻城狮

安卓开发教程基础篇-多线程文件下载软件开发,断点续传技术揭秘

更多原创教程,关注微信公众平台:做全栈攻城狮。及做全栈攻城狮官网:www.8z5.net

9520
来自专栏韩伟的专栏

编写可复用的服务端软件系统应该注意的五个重要细节

编写可复用的服务端软件系统应该注意的五个重要细节 作为程序员,我们往往希望自己写的代码能被最大程度的重用,但是我们依然能看到有很多“被重复发明的轮子”,其原因往...

390100
来自专栏大数据文摘

业界 | Dropbox力荐!我们如何应对Python桌面应用程序的崩溃

揭秘Crashpad系统如何帮助Dropbox这样复杂的桌面程序捕获并报告崩溃,且兼容Python的多种语言。

10210

扫码关注云+社区

领取腾讯云代金券