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

starwing83

回复 211# OwnWaterloo


    我说的就是这种啊！！！

OwnWaterloo

回复 212# starwing83

混着用么？ 非程序员用svn，程序员用其他的？ 其实我没试过这种。。。


嗯，不单单是编程语言（比如那个又被你提出来的coroutine...），工具也会改变人的思想。

比如，前两天，我说emacs lisp24改成lexical scope的时候。。。 你让我换vim/sublime时我问了两个问题：
1. 扩展用的语言是什么（viml是彻底不想学， python么。。。 很纠结。。。）
2. shell？

也就是说对什么是编辑器这一认识已经被emacs给扭曲改变了。 不能自己扩展功能、不能与其他程序协作的编辑器该怎么用？
（至于编辑功能比vim弱那是另一个话题，我当然是希望编辑器能有vim的编辑、能有一个不像elisp那样糟糕的扩展语言、能成为一个编程环境。。。）


至于svn -> git， 我才切换的时候就干过很搓的事。建本地中心(上游)仓库。
mkdir ~/repository/libA.git
cd ~/repository/libA.git
git init --bare
cd ~/dev
git clone ~/repository/libA.git

等记录了几个commit后， 我就反应过来了。 干嘛要去~/repository/libA.git里建个仓库。。。 完全没必要。。。 这是svn强加的概念。
对于管理本地一些不需要与他人共享的东西，比如毕业论文， 直接 mkdir ~/dev/libA && cd ~/dev/libA && git init 就完了。


最近 git -> darcs， 有发现了类似的事。 就是那个wiki。。。
因为我在工作室的时候基本到处打酱油， 你知道emacs没有配置文件就是一坨。。。  所以有时间我就写写文档算了。。。 而且是在不同的机器上。。。

darcs pull -a USER@patch-tag.com:/r/USER/wiki
编辑
darcs record && darcs push

后来我发现又傻了。。。 根本没必要把仓库全部拉下来。  只需要拉我想编辑的那个wiki page就够了。 而如果是新建一个wiki page就更简单：
创建，编辑
darcs init && darcs push

先将仓库（或者说branch）拉下来，然后更新branch的指针，最后将新的指针推回是git的做法。
darcs不需要这个概念， 要贡献推patch。
啊，我知道git也有基于patch的贡献方式，也知道有些code hosting有web界面可以编辑文件。 我想说的只是git那最常用的工作流给我造成的影响。


像编程语言一样。 有些人会称自己会N种编程语言， 但其实你看他写的代码都是一个模样。
"如果一个编程语言不能改变你的思想，那就不值得学"， 对版本控制工具也是这样。 学了git我就对hg完全没兴趣。

问题是， 一旦以新的视角去审视编程语言或工具， 体会到它们对用户思想的优秀的改变之后， 就再也回不去了。
不可能回到原始社会并且还能心安理得。。。

嗯，当迫不得已时还是得回去。 当必须用C写时改人肉分析还是只得人肉分析。 当darcs遇到性能问题时该转git还是得转git。
当。。。 遇到非程序员时。。。  上面就是一些在双方都能接受的情况下进行协作的方案。
但现在没有非程序员啊。。。  这种方案只是作为保险策略， 你不问这么一句我想都懒的去想。。。 更别说去实施了。。。


等遇见足够多的案例后。。。 我再想想该怎么处理"非文本文件"的问题。。。 现在要具体的想也是瞎想。。。
即使真的要使用分离仓库， 目标也是git那样的存储效率与darcs那样的依赖分析之间权衡， 哪怕要自己写一些代码都行。
而svn， 依然靠边站。。。 凭什么我只是想本地记录一下，大多数时候就得去中央服务器上拉取最新的？ 凭什么？
我不知道（但在接触git之前就感觉不对了）更先进的方式就算了， 但我已经知道了， 就更容忍不了svn这种落后、原始、完全不讲道理的模型。

starwing83

回复 213# OwnWaterloo


    完全同意。

关于你说的工具决定思维，深以为然。

如果照你说的，那么darcs就很先进了——一次拉一个文件，更改以后直接push patch，说的我又有兴趣了…………

就是不知道配合方面怎么样。感觉darcs比起SVN更适合做那种需要多次改动需要记住单个文件历史的版本控制工作。

git，相对于darcs，可以说是“太重量级”了吧。

在现实生活中，是一定存在和非程序员混用VCS的。我经历过很长的时间。说项目repo有8G其实很大部分是策划文档和美工的原画等等。由此可见混用的程度。如果不得不这样，那的确是没办法，这就是我提出这个方案的初衷。当然如果没有非程序员，当然全部git甚至全部darcs也不是什么问题了。

这是我提出那种方案的一个前提条件，别的我都同意你说的。

send_linux

尼玛，这书该给谁啊，这么多牛逼的评价和经验之谈.....
纠结啊

starwing83

回复 216# send_linux


    谁叫你找了个是职业程序员就肯定大把经验的领域来讨论的

send_linux

starwing83 发表于 2012-10-30 10:04
回复 216# send_linux

以后欢迎大家多提供一些大家喜欢的技术话题和方向，我们也好有针对性的找出版社合作，别弄些乱七八糟的，大家没有兴趣的图书和讨论活动

send_linux

名单已经公布！

OwnWaterloo

回复 214# starwing83

UPDATE: 这贴是网络出错，只传了一小半。。。  请直接看后续一贴。。。  幸好随手C-c了以下。。。 这么多字啊。。。


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

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


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

呃，其实能看懂，它就是记录patch的作者、产生日期、diff信息。。。
看不懂的是对binary文

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这种概念  学费也不会很贵。。。