分类 技术志 下的文章

小试git-svn

部门一直使用Subversion作为源码版本的管理工具。说实话,Subversion比较适合目前部门的绝大多数项目:没有异地团队开发,代码中心化管理;基本上都在trunk上开发,较少使用分支,基本上没有在各个branch间切换的成本。但对于我来说,有些情况下Subversion并不能满足我的需求。

问题主要集中在本地代码的备份和版本管理上。也就是说对于尚未或暂无法提交到Subversion服务器的本地代码来说,存在着被误删除和版本更新无法回退两大杯具情形。而对于这些情况,Subversion工具是无能为力的。

这时我们就需要借助其它工具来帮我们解决问题。Git就是这样一款很给力的工具,它是一款分布式版本管理工具,由linux的缔造者Linus Torvalds设计并实现,具体关于Git的介绍和使用方法可参见其官方站。这里要说的是Git是如何做到既可以管理好本地代码又可以与已有的SVN中心库进行同步的。

支持去中心化,是Git与生俱来的特性,它在本地保留了从中心服务器clone出来的源码库的全部信息,这样,你在本地修改完代码后便可以直接提交到本地的代码版本库中。本地代码的备份和版本管理的问题就这样被Git轻而一举的就解决了。而本地源码库与SVN中心源码库的同步操作则是由Git提供的git-svn工具来完成的。

git-svn默认包含在Git的安装包中,不过在Ubuntu中,git-svn是作为一个独立的Package需要额外安装的(sudo apt-get install git-svn)。安装后你就可以使用git svn xxx命令来操作中心SVN代码库了。当然如果你要使用与git svn等价的git-svn命令的话,你还需要将/usr/lib/git-core配置到你的PATH环境变量中,否则Shell会提示你无法找到git-svn这个命令。

* 检出一个已存在svn repository(类似于svn checkout)
我们可以通过git-svn clone命令完成这个操作: git-svn clone your_svn_repository_url

* 从中心服务器的svn repository获取最新更新
这个操作可以通过"git-svn rebase"完成。注意这里用的是rebase,而不是update。update命令对于通过git-svn检出的svn repostory的git版本库是不可用的。

* 查看提交历史日志
这个简单,使用"git-svn log",加上-v选项,还可以提供每次commit操作涉及的相关文件的详细信息。

* 将本地代码同步到Svn服务器
完成这一操作需要通过"git-svn dcommit"命令。这个命令会将你在本地使用git commit提交到本地代码库的所有更改逐一提交到svn库中。加上-n选项,则该命令不会真正执行commit到svn的操作,而是会显示会有哪些本地变动将被commit到svn服务器。git-svn dcommit似乎不能单独提交某个本地版本的修改,而是一次批量提交所有与svn中心版本库的差异。

下面是一个git-svn的一般使用流程:
1、git-svn clone your_svn_repository;
2、修改本地代码,使用git add/commit将修改提交到本地git库;
3、定期使用git-svn rebase获取中心svn repository的更新;
4、使用git-svn dcommit命令将本地git库的修改同步到中心svn库。

使用git-svn处理代码冲突的步骤有些繁琐,不过瑕不掩瑜吧。这里用一个小例子来说明一下。

假设某svn中心库上的某个项目foo中只有一个源码文件foo.c:
* 我在使用git-svn clone检出版本时,foo.c当时只有一个commit版本信息:"svn v1";
* clone出来后,我在本地git库中修改foo.c,并通过git commit提交到本地git库中,版本为"git v1";
* 不过与此同时另外一个同事也在修改foo.c这个文件,并已经将他的修改提交到了svn库中,版本为"svn v2";
* 此时我使用git-svn dcommit尝试提交我的改动,git-svn提示我:
  Committing to svn://10.10.1.1:80/foo …
  M foo.c
  事务过时: 过期: ”foo/foo.c“在事务“260-1” at /usr/lib/git-core/git-svn line 570
* 使用git-svn rebase获取svn服务器上的最新foo.c,导致与foo.c冲突,不过此时svn版本信息已经添加到本地git库中(通过git log可以查看),git-svn rebase提示你在解决foo.c的冲突后,运行git rebase –continue完成rebase操作;
* 打开foo.c,修改代码,解决冲突;
* 执行git rebase –continue,git提示我:
    You must edit all merge conflicts and then
    mark them as resolved using git add
* 执行git add foo.c,告知git已完成冲突解决;
* 再次执行git rebase –continue,提示"Applying: git v1",此时"git v1"版本又一次成功加入本地版本库,你可通过git log查看;
* 执行git-svn dcommit将foo.c的改动同步到svn中心库,到此算是完成一次冲突解决。

别忘了测试你的假定

周四下午,收到同事的一封mail,他告诉我他的业务代码中使用的一个库接口的行为与预期不同,并在mail中给出了测试代码和测试结果。而这个接口是之前由我封装实现的。 

这个库仅仅是对libevent做了一层薄薄的封装,目的是使其接口的使用方式符合部门的一贯风格。虽说封装简单,但单元测试也是一应俱全,不敢马虎,必要的地方mock也一并上阵,总体来说我个人还是比较满意的。

不过还是出现了问题,问题出在libevent提供的timer的行为上。这是我们第一次使用libevent,我基于以前对timer的事件处理机制的理解作出了错误的假定:libevent提供的timer是PERSIST的。同事的测试结果却表明这个timer设定是一次性的:只运行一次便失效了,除非在timer的callback handler中重新添加timer事件。

程序员修炼之道》中在介绍如何深思熟虑而不是靠巧合编程时说过:要测试你的假定。我恰恰是在这块儿犯了错误。尚没有明确libevent的行为就做出了假定而且没有对这个假定做细致测试,最终导致了这个问题的发生。

这个问题最终是这么解决的:了解了一下,libevent 1.x.x版本确实不支持persist timer事件处理,但是在libevent 2.x.x版本中,作者增加了对persist timer的支持。我们原本使用的是1.4.10的libevent,为了支持persist timer,我将库升级到2.0.10(已经是stable版了)。不过仅仅是升级库版本还是不行的。我们不能直接使用libevent提供的evtimer_set接口,因为使用该接口后,我们得到的依旧是一次性的timer。这里需要用event_set(e, -1, EV_PERSIST, eh, arg)替代evtimer_set(e, eh, arg),这样设置后得到的timer才是persist的。 

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats