我前面说的问题这就证伪了？我只是不太想继续这个讨论而已。我真心觉得都2022年了，还花很多时间讨论这个问题挺无聊的。

那么我就来回答下你的问题，首先为啥是2013年前后的帖子，因为svn vs git的情况是这样的：



这样的对比图有很多，也有很多个维度，你可以自己去确认。在2021年根本就没人讨论svn，很多图的时间轴到2016年就截至了。那我可不就是只能从svn还有很多人在用的时候去找例子嘛？

其次，4G这个数字看似撞到了一些限制，唯一相关的就这个fat32的4G单文件限制了。其他的几个32位转64位的限制都是2G的，比如linux下32位系统的内存和单文件限制都是2G。32位和64位系统切换那是更早的事了，2013年机械盘2T就800块钱，固态盘256G的报价是1000-1500，也都进入主流范围了，win7都发售4年了。你真心觉得人家这服务器用的还是fat32，还花了2天时间才发现并解决了这个问题？你这个猜测是非常主观的，远不足以成为“证伪”的依据。

最后，我举这个例子也不是说svn checkin一个4G文件就崩，如果是这样早就没人敢用svn了。所以你也不用举前面的checkin 100G不崩的反例。我说的是vcs不适合checkin大binary，容易出问题，并且也毫无收益，这里无关是svn还是git还是别的什么东西。简单地说就是你不应该把vcs当一个ftp使。至于svn是否容易崩那是另一个问题，这本身也不罕见，我那截图里面下一个人就说他一点也不奇怪，同时也是为啥git要把去中心化纳入设计思想的原因。类似的例子你也可以自己去搜，当然git也是会崩的，哪怕号称stone stable的ext4一样能搜到很多崩的例子，在对比谁更stable这个话题上要做非常细致的调研工作才能导出有意义的的结论。如果你很在意这个结果当然可以把它分析的足够清楚，但还是那句话，在2021年svn是连围绕它的讨论都几乎没有了。耗费很多力气去研究一个没几个人关心的东西是不是stable，我觉得太无聊了。

至于你对git是否有偏见么，我只能说，你无法知道你不知道的东西。你说的问题，在我看来就是git的先进性的体现。比如git checkin大的repo，尤其是有很多大的二进制文件场景下性能是很慢的，git选择放任这个问题的存在，svn用了一个聪明的小伎俩workaround掉了这个问题。你从用户的角度当然觉得svn更好更实用，但我站在设计的角度认为git的做法才是更先进更明智的，svn的方法只是制造了一团dirty work。你如果接受不了这个理念，那就探讨不出个啥来。我这里可以举一个例子说明这种理念的优越性：git的底层是一个文件系统，你说的问题本质上是这个文件系统的能力问题。微软后来整了个vfs for git，用一个真正的文件系统替换了git的这个底层，还弄了一个弱化版叫scalar，就是设计成用来解决超大规模git repo的性能问题的，包括你需要的这个checkin一个超大的binary在内的需求都没问题。微软自己内部就用这个，一个repo 100G起步。这就是git超前的理念带来的好处。对应的，svn作为一堆dirty work拼出来的刚好够用的东西，它的天花板就到此为止了。这也是为啥它现在dead了，而git还在不断进化的根本原因。

所以最终就你的问题，我还是认为vcs只适用于追踪humanreadable的ascii文本的管理。vcs的核心价值不是存储和查找，而是让你能分析、比对、合并。所有的二进制文件本就不应该是vcs管理的东西。虽然一个工程中会有大量二进制文件，但正确的做法是丢到某个文档管理系统，然后在代码中用脚本去pull你需要的二进制文件。对于firmware的binary，一个编译好的可执行文件等等，这些都是工程产物，也不应该出现在vcs里面，应该丢个makefile按需动态build。所以比起往repo里直接checkin大binary，git lfs的思路才是更正确的路线，git annex也一样。他们都只保留binary的线索，用其他手段去pull这个binary。其实我更喜欢git annex，因为它可以自由的选择从哪个就近的数据源里去取binary。git lfs做的死板一点，把一个大binary包装的好像是git在管理的文件一样，这个试图摸除两者差异的理念也是我不喜欢的。要把binary塞进vcs，你得能切实的控制住它的副作用才行（因为它没什么好处，所以必须不能有太多坏处）。所以必须做到vfs for git一样，文件系统可以partial checkout，同时又不失git的多点备份的理念，这显然是另一个维度的巨大工作量，git选择先简化处理也没问题。

最后我谈谈我的理念。我对任何工程问题，观点一向是：“先看对错，再谈好坏”。一个做对了但做的不够好的方案，是可能被一个做错了但做好的方案超越的。工程问题又特别讲究平衡和妥协，所以经常会有原则要让位于妥协的场景。在这个时候不同的人的选择就表现出不同的品味。比如你跟我都是宁可接受一个对的但做的不够好的方案，也不能接受一个首先就做错了的方案。好比你对gd32这几个硬件bug上的看法，我就觉得这不是什么小问题，错的就是错的。这是工程师应该有的追求，否则就不叫工程师，只能叫修补匠了。但在这个问题上，我感觉你确实是还没get到git的本质，做了错误的判断。

【 在 spadger 的大作中提到: 】
: 嗯，我对git没有误解也没有偏见，git也是我的常用工具。
: 这是个纯技术探讨，你可以继续举例子，git在管理硬件图纸之类文档对svn有什么优势
: ，或者svn有什么劣势。
: ...................
--
FROM 180.158.58.*