日志标签 版本控制
Android repo 魔法
8月31日
Android 为企业提供一个新的市场，无论大企业，小企业都是处于同一个起跑线上。研究 Android 尤其是 Android 系统核心或者是驱动的开发，首先需要做的就是本地克隆建立一套 Android 版本库管理机制。
Android 使用 Git 作为代码管理工具，开发了 Gerrit 进行代码审核以便更好的对代码进行集中式管理，还开发了 Repo 命令行工具，对 Git 部分命令封装，将 百多个 Git 库有效的进行组织。要想克隆和管理这百多个 Git 库，还真不是一件简单的事情。
在研究 Repo 的过程中，发现很多文档在 Google Group 上，非“翻墙”不可看。非法的事情咱不干，直接阅读 repo 的代码吧。
阅读全部内容 »
Repo——另一个Git协同模型
8月31日
Git 的神奇之处在于，你可以用很多不同的方式来使用它，而不像 Subversion，只有集中式一种方式。
最近又发现了一个 Git 新的协同模型 —— Repo，这个协同模型对于一个项目用到了多个Git版本库的协同开发非常有效。
实际上，这是上周在给一个团队做 “Git培训” 时，发现该团队在 Android 开发中，需要使用 Repo 这个工具来维护 Android 代码。于是花了些时间研究，补充了新的一章到讲义中…
Subversion管理后台增加对SVN容灾的支持
8月29日
群英汇Subversion版本控制系统提供的基本服务，实际上已经包含了简单的容灾实现：
- 在本机使用 gistore 进行数据备份
- 在备机上用 git pull 进行每日一次的数据同步
这个方法对于大多数公司，对于非核心数据的容灾备份已经足够，但是对于代码，不同的公司有着不同的敏感度，可能每日一次的备份就不合适了。
最近在给一个客户进行SVN版本控制系统的实施时，就碰到了SVN服务器间建立镜像和实时备份的需要
- 两个异地的开发团队，每个团队工作在不同的本地版本库，可能会参考（读取）异地不同版本库的内容
- 异地团队中间通过无线网桥互联，互联网桥的通讯质量易受到环境、气候的影响
- 如果两个异地的SVN服务器能够互做镜像，可以实现双机热备
- 一个团队可以在本地的主版本库中读写，一旦有数据写入本地版本库，就会同步到无线网桥另外一端的版本库。反之亦然。
- 由于本地还提供无线网桥另外一端版本库的镜像，因此访问远程版本库可以改用本地镜像进行访问，实现本地读取速度。
如果需要写入，配置 SVN反向代理，实现透明的远程写入。
Subversion可以使用 svnsync 这一工具实现版本库的远程镜像，但是如果使用手工配置，对于客户数量众多的版本库，难以维护。加之很多版本库本身很大，从头建立同步可能会非常缓慢。
我们通过在SVN管理后台增加了一对儿插件，实现了对SVN容灾（镜像）的图形化配置界面。
阅读全部内容 »
爱上Git——《Git培训讲义》摘录
8月17日
群英汇的开源版本控制系统服务和咨询主要是基于Subversion，群英汇的开源项目管理系统平台主要集成的也是Subversion。但是我们公司（群英汇）内部的开发一直在使用Git，所以实际上，我们在Git上也有着丰富的使用和管理经验。
最近一个客户选择了我们提供Git的培训和部署服务，于是从上周开始着手准备《Git培训讲义》。
这个客户是有着实际的需求，才不得不从 Subversion 迁移到 Git，虽然只是公司的部分项目组。
《Git培训讲义》中开头有一章，我给它命名为“爱上Git”，抓眼球是其次，主要是先让用户能够立刻“爱上Git”。
阅读全部内容 »
Git 服务器软件 gitosis 的改进
7月20日
群英汇内部的 Git 服务器使用 gitosis 软件架设，能够实现针对版本库的授权，以及基于公钥的安全的无口令的版本库访问。
在 Gitosis 的使用过程中，我们根据需要对其进行了改进，以满足我们对授权和版本库管理上的需求：
- 增加了管理员角色，只有管理员才能够创建版本库
- 原来的实现只有 readonly 和 writable 两种权限，其中 writable 可以创建版本库。
- 我们权限分为三级：read/write/admin。拥有管理员(admin)权限，可以创建版本库，并自动具有读(read)写(write)权限
- 拥有写(write)权限也包含读(read)的权限
- 如果没有设置权限，禁止范围版本库
- 版本库匹配支持通配符，这样在授权的时候，可以用通配符为某个目录下的所有代码库授权
- 原有的实现，在配置文件中必须写入完整的版本库名称（路径）
- 当我们增加了管理员的概念后，增加通配符，就可以为特定的命名空间进行授权，而无须因为某个管理员要建库，还要修改授权文件
- 有了通配符后，读写权限的设置也更为简单。
- 通配符支持？，* 和 **。问号匹配一个字符，* 匹配任意字符（路径/字符除外），两个星号匹配包括路径分割符在内所有字符
- 增加了版本库路径映射的可用性。版本库路径映射在代码库重构中非常有用
- 增加了正则表达式匹配路径和替换映射
- 在权限检查的路径命中之后也检查路径映射，可以减轻错误配置的可能性
- 创建版本库只有写操作才进行，读操作不创建版本库
- 原来的实现支持即时创建版本库，在读取一个不存在的版本库时自动创建
- 读操作创建库，这会导致很多因为版本库克隆时路径输入错误导致错误建库
- 我们更改后，只允许在写版本库时并且具有 admin 权限才初始化新的代码库
- 版本库名称中允许出现中文（UTF-8）
- 基本上版本库命名都用英文字符，不过有个客户提出来支持中文版本库，我们就添加了这个支持
下面，拿一个配置文件来说明：
Subversion 用户眼中的 Git (13): Git 成为 SVN 的伙伴？
5月30日
很多公司不能代码开源，甚至也不能实现内部的代码开源，这相当大的原因是政治原因，而非技术原因。
那么当工作在 Subversion 的版本库下，是不是就和 Git 绝缘了呢？
非也，答案就是 Git-svn。
Subversion 用户眼中的 Git (12): Git 有属性么？
5月30日
除了在前面比较过的部分检出，路径授权等，还有一些 Subversion 的特性，在 Git 中的实现存在差异。用户最关心的可能就是：属性。
是的，Git 也有属性的概念，但是和 SVN 的属性并非一一对应的。
阅读全部内容 »
Subversion 用户眼中的 Git (11): Git 授权没有 SVN 那样精细
5月17日
的确，Git 的授权做不到 Subversion 那样按照路径进行授权。
Subversion 可以通过授权文件，将权限设置到每一个路径。但是也有缺憾，即权限不能在分支中继承。例如为 /trunk 及其子目录的授权，不能继承到分支或者里程碑中相应的目录下。群英汇通过泛路径授权能够简化分支授权的配置，但毕竟也还是需要进行配置。
Git 的授权模型只能实现非零即壹式的授权，要么拥有全部的写权限，要么没有写权限，要么拥有整个版本库的读权限，要么禁用。
从技术上将，Git 可能永远也做不到类似 SVN 的路径授权（读授权）：
- 如果允许按照路径授权，则各个克隆的关系将不再是平等的关系，有的内容多，有的内容少，分布式的理念被破坏
- 如果只有部分路径可读，则克隆出来的提交和原始提交的提交ID 可能不同。因为提交ID是和提交内容有关的，克隆中提交的部分内容被丢弃，势必提交的 ID 也要重新计算
- 允许全部代码可读，只允许部分代码可写，在版本控制的管理下，是没有多大实际意义的，而且导致了提交的逻辑上的不完整。
那么有什么办法来解决授权的问题么？
- 公司内部代码开放。即代码在公司内部，对项目组成员一视同仁的开放。
就像上周末在北京 OpenParty 上， ThoughtWorks 工程师所说的，虽然我并不是非常认同：公司内部对代码进行精细控制没有意义。代码没什么好隐藏的，有的公司代码拿出去还有害。（因为代码太烂？）
- 公司对代码库进行合理分解，对每个代码库分别授权。即某个代码库对团队成员完全开放，对其它团队完全封闭。
- 公司使用 Subversion 做集中式的版本控制，个人和/或团队，使用 Git-svn。这样在无法改变公司版本控制策略时，程序员采用的变通之法。
- Git 服务器的部署实际上可以使用钩子对 分支和路径进行写授权，即可以控制谁能够创建分支，能够写特定文件。
您有什么更好的建议呢？
Subversion 用户眼中的 Git (10): Git 命令行的人性化设计
5月9日
Git 命令行的人性化设计？刚刚接触 Git 的 SVN 用户一定不予认同。
因为在 SVN 用户看来，co 必须严格写成 checkout, ci 必须严格写成 checkin，st 必须严格写成 status 的版本控制系统，怎么能说成人性化？
容我慢慢道来。
阅读全部内容 »
Subversion 用户眼中的 Git (9): 单亲 VS 多亲
5月1日
SVN 和 GIT 对比的系列博文尚有几篇一直放在草稿中，处于构思阶段，今天从故纸堆里检出来（checkout?）
我们在《Subversion 用户眼中的 Git (7): 完全不同的分支和里程碑的实现》中介绍过，Git 和 Svn 的分支实现机制完全的不同，这也直接导致了 SVN 在分支合并中困难重重。尽管在 SVN 1.5 之后，通过 svn:mergeinfo 属性引入了合并追踪机制，但是在特定情况下，合并仍会出现很多困难。
在《SVN 树冲突和目录丢失问题（1）》系列博文中，介绍了帮助我的一个朋友解决SVN树冲突的过程。这实际上在 GIT 中是 “a piece of cake”。你可以用 Git 模拟一下不同分支中文件目录改名引发合并冲突，在Git 中解决的是那么自然和漂亮！
这是为什么呢？因为 SVN 是单亲家庭，而 GIT 是双亲/多亲家庭啊。
最新评论