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

OwnWaterloo

回复 60# starwing83

关于速度。。。很多软件，速度都不是第1位的。 速度只要足够快就可以了。
git对我来说最大优势绝对不是速度。 我可是在Windows上用msysgit，从来就没享受过。。。
或者这么说，依然比乌龟svn要快， 但我不会因为git在linux上更快这一个理由就切换到linux上去。
你是不是又开始为了给自己找论据就把速度作为git的最大优势了。。。

meego2012

好壮观，擦不上嘴，投个票........

svn公司在用，git个人爱好，用的不咋地

OwnWaterloo

回复 62# starwing83

对，这完全可行。有两个问题：
1. 文件不能交叉放， git不能管理.git之外的
2. 必须一开始就想好模块划分 —— 对网站来说是应该的， 但对notes。。。

你还记得我想过一些办法让git管理.git目录之外的文件，以及一个目录下有多个git仓库么。。。
最后还是觉得太危险，稍不留神就弄错。。。

这些不便 —— notes一开始没有分离的需求； 很多软件的配置文件都在~/下，又不想把它们都作为一个仓库 —— 都是从平时生活中体会到的（只有网站是刚编的例子）。
然后看看darcs，发现用git的种种不便都木有了。。。
至于速度。。。  notes撑死了不过10M、 配置文件总共撑死了上不了M。。。  有啥好担心的。。。

我说的commit的大量修改会造成麻烦不仅仅是只要重新下载那点速度，而是每个人得去rebase，这很不方便。。。
哪怕就是重新下载然后rebase比darcs快又怎样。。。  只要darcs不是慢得伤心， 人家方便啊。。。

starwing83

回复 63# OwnWaterloo


    没有版本号我可以理解………………

没有单线历史我也可以理解（多线历史么……）

完全没有历史是个什么情况？？？？

我只问你，我现在想undo到两周以前的情况去，这两周我提交了30个commit，我怎么办？

好，这个说不准你能直接遍历所有的commit，找到两周以内的commit，然后reversed-patch？顺序怎么办？

好，你说不定能直接遍历所有的commit，找到两周以前的commit，然后patch？还是一个问题：顺序怎么办？？？？

patch可以不要顺序，可是要变成我现在这个样子，肯定要顺序啊，不要顺序的结果要么就是某个patch失败，要么就是最后出来的是啥我都不认识了！

如果是习惯上需要某个东西，比如版本号，没有，我可以接受。

可是逻辑上需要某个东西没有，那肿么办？你不能这么不负责任啊，解释清楚再走！！！

starwing83

回复 66# OwnWaterloo


    可是你也要明白，这些不是硬伤啊！

这些只是小缺陷，git的基础没有坍塌啊，是可以实现的啊！

我就是想说明这个问题。git的基础——CAFS无比牢固，可以实现其他的VCS的所有功能。

wang290

shuge_guet 发表于 2012-10-11 16:56
回复 52# wang290

就像搞女人一样，想怎么搞都行。

第一次知道git，还是因为linus的那份邮件，宣布Linux的kernel代码放托管在git上

starwing83

回复 63# OwnWaterloo


    我有个猜测不知道对不对。正如svn是以目录为单位管理文件的。darcs是以文件为单位管理文件的，每个文件，维护一个patch链表，patch给出对谁patch，并给出之前的那个patch——即每一个patch，都能追溯到最初的状态。OK

如果是这样，所有的问题就都好理解了。commit可以pick一堆patch，这本身已经可以满足commit的要求了，然后commit本身没有年代历史。

然后commit本身可以记录时间，时间又是一个天然的顺序表索引，很好，commit有顺序的。

那不同的branch咋办呢？branch就不能仅仅得到一个commit了——因为commit不知道自己是在什么基础上被commit的……

那么只有一种可能了——branch根本就没有历史，它只知道自己是什么状态（哪个commit），知道这个状态中每个文件是怎么来的（单个文件的patch），但是根本就不知道这些文件之间的相关顺序！也不知道是经历了哪些commit来的！

这应该就是你说的意思了……

这样好么……………………………………最显然的一个问题就是，你无法undo到上个commit！你无法保证文件的统一一致性，你只能够知道当前状态，但是你无法恢复到整个文件夹的上一状态——因为你根本就不知道上个状态是啥！

如果commit带parent，那git的问题darcs仍然无法避免，别人依然需要重新rebase。

而且，如果commit带parent，那么就和git一模一样，git的blob也是按照diff存放的，记得么？理论上，保存方式都一样，完成相同的功能也不是不可能的。

所以你必须解释一下。

OwnWaterloo

回复 67# starwing83

走不仅仅是要干活的原因。。。  还有个原因是我也不知道啊。。。
我就是在年初被你坑了去学haskell的时候顺带了解了一下，很多细节忘了啊。。。

>> 我只问你，我现在想undo到两周以前的情况去，这两周我提交了30个commit，我怎么办？
>> 好，这个说不准你能直接遍历所有的commit，找到两周以内的commit，然后reversed-patch？顺序怎么办？
>> 好，你说不定能直接遍历所有的commit，找到两周以前的commit，然后patch？还是一个问题：顺序怎么办？？？？

patch肯定有个提交时间。找出所有提交时间在两周前的作为set，构造working tree不就完了。。。
darcs专门有提performance的问题（你看git的官网都不会提这个，人家自信得很）， ghc的仓库也是因为这个原因从darcs换到git了。这真是一个悲剧。。。

但不是所有工程都有上万，十万，百万的patch。。。
对肯定没有这种需求的，比如notes和个人的配置文件。。。   慢点就慢呗。。。

不过好像darcs是会对最近的set的改动进行缓存的。


那你再帮我想个方案。。。 怎么管理配置文件。。。  很多软件都是在~/下吧？ 没有其他地方。。。
如果是darcs， 就可以在~/下产生一个仓库， 每个软件对应一个set。 哪个软件的配置文件改了就将这个patch添加到对应的set。
如果有人找我要某软件的配置文件， 只需要把这个set给他就可以了。
而且还可以增加一个总的set， 在新的机器上直接拉取这个总的set。

我现在。。。  是~/.gits， 里面有各种软件的.git。。。 然后用ln -s 控制~/.git 指向 ~/.gits/ 下的某个软件的.git。。。
比较安全。。。 但很麻烦的啊。。。
而且要在其他机器上复现得一个一个仓库分别下载。。。

OwnWaterloo

回复 68# starwing83

对，git的format清晰有优势。。。
darcs好像没有这方面的specification， 而且format还改过一次。。。不知道darcs的作者是否能意识到有repo format spec是很重要的。


但git格式清晰又怎样。。。 blob可以复用， tree可以复用， 但commit基本就没用处了。。。
得有一个新的概念， 比如叫set。 以及它的相关操作。。。 这基本就是在实现半个darcs了。。。  你愿意做么。。。 你愿意做我就愿意用


还是做与不做的问题。。。

starwing83

回复 72# OwnWaterloo


    好，达到这个共识我就满意了………………接下来就是做与不做的问题了，我满足了。

如果以后需要这个特性，大不了写脚本实现set得了。

OK，下一个话题。


你看看我70L的发言，我就问你一个问题：commit能带时间，OK你赢了，可是你忽略了一个很悲惨的事情……

…………………………分支怎么办…………怎么支持分支……如果这样还不如用git，因为你只有一个分支——因为你只有一条时间线…………


好，如果每个分支都有自己的commit，也可以解决问题，但是很遗憾的……这就是SVN了，妥妥的……完全一样了。如果真的是这样，darcs就是单文件track版本的SVN，木有任何区别了，对我来说也就没啥吸引力了……

Over~