Subversion
Subversion 用户眼中的 Git (7): 完全不同的分支和里程碑的实现
2月21日
Subversion 曾经骄傲的宣称，自己的分支是轻量级的，眨眼之间分支立现。但是说实话，Subversion的分支和里程碑，是 svn copy 命令的副产品，好像是折衷的产物。
Git 分支一出，无人敢于争风，信乎？
阅读全部内容 »
Subversion 用户眼中的 Git (6): stage
2月9日
不单单是 Subversion 的用户，还包括其他类型的分布式版本控制的用户，如 Hg 的使用者，都可能会对 Git 的 stage 或称为 index 的东西感到非常的陌生。
但是一旦你熟悉 Git 的 stage 的秉性，你就会喜欢上它。
版本库整理的内存溢出问题
2月4日
我在博客 Subversion 版本库整理实战 中为用户提供的 Subversion 版本库整理宝典 
，在客户那里没有奏效。通过几个邮件的往来，决定还是专门写一个博客，因为通过博客后面的评论来回复，编辑功能太弱，要写 HTML，所以以文章形式汇总一下。
客户目前遇到了两个问题：
- 一个是导入到新版本时提示目录不存在
- 另外一个就非常诡异，错误输出是：
svnadmin: 转存流在“Out of memory - term”包含错误头部（没有“:”）
第一个问题很好解决，第二个问题可真是一个大麻烦。
Subversion 用户眼中的 Git (5): 没有部分检出
2月1日
Subversion 可以将整个库检出到工作区，也可以将某个目录检出到工作区。对于要使用一个庞大、臃肿的版本库的用户，部分检出是非常方便和实际的。
但是 Git 只能全部检出，不支持按照目录进行部分检出。
那么这是为什么呢? —— Subversion 用户问道。
阅读全部内容 »
Subversion 版本库整理实战
1月27日
在使用 svnadmin dump, svnadmin load, svndumpfilter 等命令对 Subversion 版本库裁减，可真的不是 a piece of cake. 有很多技巧，窍门和陷阱。
这不，今天一个客户的电话，就涉及到了 svn 版本库裁减的好些问题：
- svndumpfilter 命令后面的 include 或者 exclude 子语句，后面的多个路径用逗号分割可以么？
- svndumpfilter 命令后面的 include 或者 exclude 子语句，后面的路径可以使用通配符么？如何使用？
- svndumpfilter 命令涉及的路径非常多，在命令行写太复杂了，甚至可能超过 SHELL 对命令行长度的限制，该如何？
- 重新整理的版本库为什么有很多空的提交，说是为了占位之用？
- 重新整理后的版本库的路径可以改变么？
Subversion 用户眼中的 Git (4): 全局版本号和全球版本号
1月25日
Subversion 的全局版本号和 CVS 的每个文件都独立维护一套版本号相比，是一个非常大的进步。在看似简单的全局版本号的背后，是 Subversion 提供对于事物处理的支持，每一个事物处理（即一次提交）都具有整个版本库全局唯一的版本号。
Git 的版本号则更进一步，版本号是全球唯一的。也可以说是全宇宙唯一的。 
Git 对于每一次提交，要将包括作者，提交内容等在内的信息整个作一个 SHA1 哈希，进而得到版本号。版本号得到一个 40 位十六进制字串。
什么？40位长的版本号？
Subversion 用户眼中的 Git (3): 命令集不兼容
1月19日
SVN 用户对 Git 的不好的体验，可能大多来自于两者命令集差异很大，不兼容，感觉非常不习惯。
这其中的一部分原因是因为 SVN 和 Git 的原理不同，分属不同阵营——集中式和分布式版本控制；另外一个重要的原因，可能就是 Linus Torvals 痛恨 CVS，而且 Torvals 曾经说过的很有争议话，就是他认为 SVN 也是一个失败。所以，Torvals 设计的 Git 当然要特立独行了。
不过…
阅读全部内容 »
Subversion 用户眼中的 Git (2): 版本库, 工作区如影随形
1月15日
Subversion 的工作区和版本库截然分开，工作区中的修改要提交到版本库，可能是本机另外一个目录的版本库，也可能是通过网络连接到服务器上的版本库。
而 Git 的工作区和版本库是如影随形的。没有使用过分布式版本控制系统的 Subversion 用户可能会感到困惑，也可能将如影随形的 .git 目录看作是 Subversion 工作区中的 .svn 目录的等价物，那可就错了…
阅读全部内容 »
Subversion 用户眼中的 Git (1): 集中式 vs 分布式
1月14日
“Git 很古怪” —— 使用 Subversion 的用户说道。
那么从 Subversion 用户的角度来看，Git有哪些古怪之处，或者说特别之处呢？
我们将会以连载的方式一一道来。
如果您有什么建议和补充，或者想知道 Subversion 中的某个 git 对应物，可以在博客后留言 …oO
两种不同类型的版本库：集中式和分布式
Subversion 属于集中式的版本控制系统：
- 每个版本库有唯一一个“官方地址”，每个用户都从这个唯一地址获取代码、数据；
- 获取代码库的更新，也只能连接到这个唯一的代码库，同步以取得最新数据；
- 提交必须有网络连接（非本地版本库）；
- 提交需要授权，如果没有授权，提交失败；
- 提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类
- 冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决
Git 属于分布式的版本控制系统：
- 众生平等，每个检出(checkout)的版本库，或者更准确的说每个克隆(clone)的版本库都是平等的。
你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。 - 获取版本库的更新，可以来自任何源。
你可以从张三那里获得上游的改动，包括张三自己的提交；你也可以从李四那里获得上游的改动，也可能包括李四的提交。 - 提交完全在本地完成。无须别人给你授权，你的版本库你作主。
当然你在你的版本库中的改动是否别人愿意合并到他们的版本库则是另外的一回事了。 - 提交总是会成功，因为提交是在本地进行的么。
甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支 - 冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决
- Subversion的提交竞赛，在多人协作开发时，提交经常被打断。坏的体验
- Git 的每个用户就好像工作在独立的 Feature Branch （功能分支）中
- Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库
合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成
- Subversion的提交竞赛，在多人协作开发时，提交经常被打断。坏的体验
Git 也可以模拟集中式的工作模式
- Subversion只有一种集中式的工作模式
所有人都和服务器同步，提交直接到服务器上 - Git 也可以模拟集中式的工作模式
- Git版本库统一放在服务器中
- 可以为 Git 版本库进行授权：谁能创建版本库，谁能向版本库PUSH，谁能够读取（克隆）版本库
- 团队的成员先将服务器的版本库克隆到本地；并经常的从服务器的版本库拉（PULL）最新的更新；
- 团队的成员将自己的改动推（PUSH）到服务器的版本库中，当其他人和版本库同步（PULL）时，会自动获取改变
- Git 的集中式工作模式非常灵活
- 你完全可以在脱离Git服务器所在网络的情况下，如移动办公／出差时，照常使用代码库
- 你只需要在能够接入Git服务器所在网络时，PULL和PUSH即可完成和服务器同步以及提交
- Git提供 rebase 命令，可以让你的改动看起来是基于最新的代码实现的改动
- Git 有更多的工作模式可以选择，远非 Subversion可比
最新评论