Skip to content

Archive

Tag: hg
从今天开始,KlayGE的源代码已经可以通过git来访问了。以后的更新也会都通过git进行,旧的hg访问会逐步删除。整个迁移的过程还算比较顺利的。最终经过精简的git库有90M左右,比原先需要下载576.8M的hg库小得多了,虽然精简过的hg库才16M。 新的地址 新的git地址可以在这里找到。国内访问github的速度应该会高于sourceforge或者bitbucket。 转移过程中遇到的问题 上一篇文章里记录了精简hg的方法。精简过的hg可以用TortoiseHg内置的hg-git转成git库。和从hg导入git的方法和坑的实验不一样的是,现在的hg-git可以直接在命令行下推到一个bare库,不需要经过bash。所以这个过程可以直接用一个bat搞定。 尚未解决的问题 目前把新的库推到了g ...
前不久提过关于迁移到git的想法,是时候做一个详细的计划了。为此,我专门在github上启动了一个KlayGE2Git的项目,用于存放迁移过程中需要的脚本。希望对其他也有类似计划的朋友能有所帮助。 需要完成的事情 最终选择的迁移方案是方案4:单一repository,下载外部库发行版。所以在迁移的过程中,需要考虑如何减少repository大小,以及考虑迁移之后工作流需要的改变。 删除当前工作目录的大文件 第一步应该是删除当前工作目录的大文件,主要是二进制资源文件。并且需要在cmake里面加上自动下载的脚本,以便在配置工程的时候可以从klayge.org上获取需要的文件。否则后面开发的时候会有问题。这一步已经完成,目前的hg上已经没有资源文件。 ...
前不久有人问我是否把版本控制考虑转移到git的事情,其实我在2013年就写过一篇从hg导入git的方法和坑,里面给出了转移的实验,但没有具体计划。已经1年多过去了,git的工具和工作流也慢慢成熟。虽然git仍有一些基础上的缺点,比如无法进行文件改名以及轻易就可以改变历史记录,但由于有submodule和轻量的分支,再加上github的发展,从用户采纳程度来看,在git和hg的竞争中,git已经胜利。是时候再次考虑这个问题了。 需要注意的是,目前KlayGE的hg repository已经超过500M,初次pull的速度很慢,每次push的性能也受其影响。如果能在转移到git的过程中解决这个问题,这样的转移才有意义。否则只是换汤不换药。 几个选择 转移到git有多种 ...
最近不少朋友提出为何不把KlayGE推到github的问题,原因是目前github只支持git,而我暂时不打算从hg切换到git。我原先觉得,既然有hg-git这样的插件,这件事情技术上应该很容易,直接转就可以了。试验了一下,发现其实还存在一些坑,必须要对付。这里拿空明大牛的salvia的repository为例子,试验从hg转到git。 第一次尝试,直接转换 安装了hg-git之后,建立一个叫做salvia-git的目录,在里面初始化一个git repository。然后在到salvia-hg的目录,直接执行hg push ../salvia-git。结果在执行了很久之后,出现 pushing to ../salvia-git abort: The system cannot find the file specified 以失败告终。 第二次尝试,bare 在初始化git r ...
由于sourceforge和bitbucket在国内的访问速度较慢,我在codeplex上申请了个空间http://klayge.codeplex.com/用于存放KlayGE的repository。Mercurial clone的地址是https://hg01.codeplex.com/klayge。如果你不满现在的访问速度,可以考虑用这个新的。