2010-05-17

Subversion 用户眼中的 Git (11): Git 授权没有 SVN 那样精细

的确,Git 的授权做不到 Subversion 那样按照路径进行授权。 Subversion 可以通过授权文件,将权限设置到每一个路径。但是也有缺憾,即权限不能在分支中继承。例如为 /trunk 及其子目录的授权,不能继承到分支或者里程碑中相应的目录下。群英汇通过泛路径授权能够简化分支授权的配置,但毕竟也还是需要进行配置。 Git 的授权模型只能实现非零即壹式的授权,要么拥有全部的写权限,要么没有写权限,要么拥有整个版本库的读权限,要么禁用。 从技术上将,Git 可能永远也做不到类似 SVN 的路径授权(读授权):
  • 如果允许按照路径授权,则各个克隆的关系将不再是平等的关系,有的内容多,有的内容少,分布式的理念被破坏
  • 如果只有部分路径可读,则克隆出来的提交和原始提交的提交ID 可能不同。因为提交ID是和提交内容有关的,克隆中提交的部分内容被丢弃,势必提交的 ID 也要重新计算
  • 允许全部代码可读,只允许部分代码可写,在版本控制的管理下,是没有多大实际意义的,而且导致了提交的逻辑上的不完整。
那么有什么办法来解决授权的问题么?
  1. 公司内部代码开放。即代码在公司内部,对项目组成员一视同仁的开放。 就像上周末在北京 OpenParty 上, ThoughtWorks 工程师所说的,虽然我并不是非常认同:
    公司内部对代码进行精细控制没有意义。代码没什么好隐藏的,有的公司代码拿出去还有害。(因为代码太烂?)
  2. 公司对代码库进行合理分解,对每个代码库分别授权。即某个代码库对团队成员完全开放,对其它团队完全封闭。
  3. 公司使用 Subversion 做集中式的版本控制,个人和/或团队,使用 Git-svn。这样在无法改变公司版本控制策略时,程序员采用的变通之法。
  4. Git 服务器的部署实际上可以使用钩子对 分支和路径进行写授权,即可以控制谁能够创建分支,能够写特定文件。
您有什么更好的建议呢?
blog comments powered by Disqus