版本控制之道---Git时代已经来到？（获奖名单已公布-2012-10-30）

OwnWaterloo

回复 214# starwing83

其实哪怕没有非程序员，对一些二进制文件该如何存放我也是很纠结的。。。  比如lena.png什么的。。。

如果真要放仓库（以免外部链接失效），git的存储方式也很好。这种东西就应该直接按内容存放(.git/objects/)，按哈希值获取(tree object)。


darcs。。。  其实我还是不明白它的仓库格式。。。  一些肉眼观察发现两者都有。。。
_darcs/pristine.hashed/里有类似tree的东西（文化名 -> 哈希值的列表）也有类似blob的东西（好像没有长度域）。
_darcs/inventories/里类似commit的东西（patch 列表）。
_darcs/patches/里的东西我就看不懂了。。。

呃，其实能看懂，它就是记录patch的作者、产生日期、diff信息。。。
看不懂的是对binary文件它也要这样。。。
*oldhexadecimal-digits
*newhexadecimal-digits

这是闹哪样。。。patch比文件本身还要大。。。

如果是
*oldmessage-digest
*newmessage-digest
就好了。。。 不知道这与它的patch理论是否有冲突。。。

如果能把二进制存储的问题给解决了。。。 比如darcs额外管理一个tree文件， 再额外有一个工具通过这个tree文件从某个地方得到文件内容。。。
哪管其他人用什么。。。 爱用git用git，爱用svn用svn，爱用网盘用网盘，爱用文件名编码就用文件名编码。。。
当然，如果能复用git最好。。。  因为它比网盘稳定，比svn高效，还有很多现成资源（online code hosting， libgit。。。）可以用。



关于先进之处。

darcs的先进之处是在理论。。。 实现方面也许会有硬伤。。。
它理论上的先进是可以自行推导依赖，并且可以管理这些依赖（除了自行推导的，还包括人肉指定的）。

比如，假设一个项目有2个文件： week.txt, month.txt。 以及8个改动：
week init: 创建week.txt
week arabic: 向week.txt添加7行文字，依次是1-7
week roman: 将week.txt中的3改为III
week english: 将week.txt中的6改为six
month init: 创建month.txt
month arabic: 向month.txt添加12行文字，依次是1-12
month roman: 将month.txt中的12改为XII
month english: 将month.txt中的2改为two

这8个改动可以有 8! 次种顺序。 但不是所有都是有效的，它们之间有一些固有依赖：
1. arabic依赖init， 得先有文件，才能添加内容
2. roman（或english）依赖arabic，得先有内容，才能修改内容
3. roman与english之间互不依赖，因为改动的是不同位置
4. week 与 month互不依赖， 因为改动的是不同文件

满足这些依赖好像还有200多种顺序的样子。 8! / [ (4! / 2) * (4! / 2) ] = 280， 对么？


对darcs来说，它认为这280种顺序得到的仓库都是相同的。参与这个项目的人，无论他以什么方式得到这8个patch， 他就得到了相同的仓库。

而其他版本控制软件都有年代顺序，除了那些固有依赖，还有年代顺序的依赖。
不仅仅要求这8个patch的内容相同，还要求它们被apply的顺序也相同，在所有参与这个项目的人的仓库里都相同。

svn是通过一个中心仓库来强制历史顺序。 先记录的就可以改动历史， 后记录的就倒霉， 得让先让自己本地的历史与服务器相同。
git本地可以随便记录，但最终还是得推上去。 这时候先推的就可以改动历史， 后推的依然倒霉。
而darcs， 只要（由不同的人，例如一个管week.txt，一个管month.txt）推了这8个patch就行了， 顺序无所谓。
并且一旦推上去了 —— 假设是month.txt的人先推的 —— week.txt的人本地也有若干记录了， 他还是可以直接拉取month.txt的人的工作， 因为顺序无所谓。


嗯，为了简化描述，例子是很极端。 不同文件之间可能还会存在一些必要的依赖。 可以通过人肉分析并告知darcs。。。
也就是说， darcs认为的依赖就肯定是依赖。 它没推断出来的也有可能是， 得有程序员自己加。
而其他vcs认为的依赖很多都是由年代顺序造成的， 与代码内容毫无关系。


为了能更有效率的多人协作，都已经使用enlive（以后可能还是要用pure）这种东西让前端的耦合尽量小了。
但现在新的瓶颈却出现在git上。。。 反而是git产生的耦合更严重。。。 你说我怎么想得通。。。 怎么不冒着风险去用darcs。。。
哪怕赔，也就赔点学习成本而已。。。  而且这已经付得差不多了。。。  接下来就等着赚了。。。



关于重量级。

我觉得也就是有了内建的对branch与index的支持。。。  branch不知道。。。 但index肯定让很多人都困惑过。。。 尤其是哪些只看cheatsheet的。。。

darcs么。。。 最坏情况就是它的学费赚不回来。。。  反正它又没有branch和index这种概念  学费也不会很贵。。。

starwing83

回复 221# OwnWaterloo


    你要觉得好，有时间我学习了darcs的理论以后自己用C实现一份好了…………

OwnWaterloo

回复 222# starwing83

还是先vime吧。。。 emacs我快受不了了。。。

flb_2001

来晚了，我们公司想管理source，现在都是各自管理，分不同模块。每个版本的功能都不清楚。

fayfarn

我觉得HG比git好多了

rover12421

唉,错过了讨论了
这本书已经看过PDF版了,写的确实很不错,但是gitolite那章比较旧了,和新版本差距还是很大的,特别是mirror这一章,书的官方站有对这章有更新,但也没跟上最新的gitolite 3.x代码.还好gitolite的文档还是比较全面的,可以参照文档操作.
我也写一篇blog讲解了在gitolite最新的 3.x搭建mirror的步骤.
http://www.rover12421.com/2013/0 ... -configuration.html

轨迹16

git确实是很强大，是分布式的