- 论坛徽章:
- 2
|
回复 80# starwing83
我前面就说过了，git相比svn的优势难道就只有本地分支？于是没有本地分支的就都应该与svn归为一类？
还有，速度是git的优势，但git的优势是不是就只有速度？
你总是抓住一些片面的地方，一些有利于你展开论述的地方来说。
现在又是patch-based。因为darcs和svn都是patch-based，所以它们又是一类了？ hg是不是patch-based？是不是也该和svn一类了？
hg的本地分支是不是从无、到扩展、最终发展到内建支持了？
是因为你推荐我学haskell，那就难免会接触到darcs。
一开始我也不能理解为什么连年代顺序都可以抛弃。
但转念一想，它确实可以解决我在用git时遇到的一些麻烦。
我再给你举个例。我偶尔会手敲一些歌的歌词。歌与歌之间都是独立的。
但每一个歌的歌词文本会改，比如我敲错了，比如有些日文汉字我熟悉了，注音就可以丢了。
我希望维护的仅仅是每一首歌的歌词的发展顺序，以及所有歌的独立的发展线。
但git，包括其他有年代顺序的版本控制工具会强制将所有歌的发展线交错在一起。
包括前面的本地的笔记，包括配置文件。。。
（啊，我都仿佛已经听见你会说：这只是你自己独特的使用方式，不是版本控制工具应该做的，它们只是用来管理代码的。。。）
哪怕我需求的不是管理代码的，就是个人杂七杂八文件的管理用的工具。但我有这样的需求是事实吧？ 说不定其他人也有。
并且用git的话，始终没找到很直接支持的方案。 而darcs恰好就支持。
总之一句话： git会强制产生一些可能不被需要的依赖。 比如前面的7个数字和2独立修改的例子。 A <-B 和 A <- C 是必须的， 但B和C就是被git强制的。
如果有一种新的思路，可以避免后面那种依赖，是不是就是其先进性的体现？
再说速度，这种新的思路会导致不可避免的效率问题？目前肯定存在，因为刚接触darcs没多久就知道ghc因为效率原因从darcs转到git了。
但那又如何呢？ 绝对不会发展到ghc那种规模的项目是不是就没有了？ 配置文件、笔记、歌词。。。 我都是手敲。。。 一辈子又能写多少啊。。。
你不能总是将效率作为第1要素去衡量一个软件，或者一种新的思路。
就像gc，或者STM，哪怕就是有效率硬伤，那又如何呢？
它们就是能避免编程的繁琐，减少出错的几率。这是已经是没有争议的事了吧？ 这效率换得值得啊。。。
这不是1,20年前了啊。。。 承受得起这点效率损失的场景越来越多了啊。。。
从使用方面， svn不如git方便， git自己又有许多不方便的地方， darcs看起来可以解决这些。 怎么能说 darcs 只是一个 better svn？
你怎么能只从实现原理方面入手呢。。。 怎么就对使用场景完全不理会呢。。。 （哦，因为这只是我的使用场景，你没有这样的case是吧。。。 我认。。。）
再早若干年， 如果提起lexical scoping， 多数人会摇摇头对你说： 这玩意没法高效实现。
再继续更早， 如果提起virtual address space， 多数人会联想到memory overlap。
在java之前， gc也没被普遍承认啊？ 但你看现在是个什么样子？ 如果只顾及实现原理而不看使用场景， 这些东西能发展起来？
至于真正的实现原理，我也不知道。因为这些原因，最终我没有实际大量用过：
1. darcs不支持non-ascii文件名， 不仅仅是歌词，有些notes都包含非non-ascii文件名。
darcs的代码我又看不懂。。。 现在可能会稍好一些， 年初那时看haskell实际代码肯定是天书般的。
2. darcs确实太小众了， 所以code hosting都很难找。。。
而git是多到不知道选哪个好。。。
那时候你说可以用git做底层，提供darcs的接口。我觉得很好，可以有稳定的支持（比如免费的私有的code hosting）。
但没那个能力去做这个事，于是还是只能用git + 各种work around。
如果你真的感兴趣， 不妨去看一看。。。 再问我也是没用的。。。 我在前面已经把知道不知道的都吐完了。。。 |
|
免费注册
楼主: send_linux
发表于 2012-10-11 19:56
发表于 2012-10-11 20:44