编程与软件工程bitquabit.com
放弃你的 DVCS，回归理智
Abandon your DVCS and return to sanity
2015 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章质疑分布式版本控制系统（DVCS，如 Git/Mercurial）的必要性，认为其带来的复杂度超过收益，主张在拥有良好分支合并能力的集中式 VCS（如 SVN）中也能获得同样的好处，呼吁开发者“回归理智”。文章引发了关于离线工作、仓库体积、协作模式等 DVCS 核心价值的激烈讨论。
为什么经久不衰：它记录了 DVCS 普及过程中一场真实而持久的争论，集中式与分布式各自的适用场景至今仍是团队选型时会遇到的问题。
HN 评论精选
逐条反驳文章论点：离线、fork、存储等问题 DVCS 都有实际优势，作者抱怨的只是易用性。
还记得 SVN 服务器宕机时，你基本只能干等它恢复才能做原子提交吗？别忘了经常出差的人——SVN 加飞机简直是地狱组合。有人经历过在乎的开源项目被删掉、却很难找到带完整历史的副本吗？还有人因为目标不同需要自己的 fork、又要频繁合并上游变更——这天生就是 DVCS 擅长解决的问题。另外：DVCS 并不排斥补丁模式（Linux 内核用 Git 就用得好好的）；存储很便宜，Git 还支持浅克隆。文章抱怨的其实主要是 UX 问题，没有好用的工具不代表以后也不会有。
iand675查看英文原文
Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let's not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell. Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky. Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. Other objections to this article: * Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) * The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal. I could go on, but the article seems to be griping about UX issues. Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.
分布式和离线能力才是 DVCS 的核心价值，作者的网络环境太优越，体会不到。
我爱 DVCS 不是因为分支做得好，而是因为它分布式——我可以离线工作，而网络并非无处不在，即使在大城市我家网络也不稳定。我说的离线工作包括 blame、bisect、log 等，不只是提交。作者二十年来只有六次需要离线看完整历史？那是因为他运气好，网络一直不错，不是所有人都这样。我也喜欢分布式带来的协作方式：别人不用拿到我仓库的提交权限，就能有完整的开发环境，然后给我发补丁或 PR。
jimktrains2查看英文原文
> Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging. No, I fell in love with it because it was distributed and I could work without an Internet connection, which aren't prevalent everywhere, and even in my house, in a large city, can be iffy. By work I mean things like blame, bisect, log, &c not just committing. > Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. Well lucky him for only being able to code when he has a nice connection, not all of us do. Also, I like the distributed aspect as well. I like not having to give people commit access to my repo for them to have a proper dev env and then they can send me a patch or a PR and we can incorporate their changes. How would they be able to make any commits or anything otherwise without access to my repository?
大型团队用 SVN 的真实经验：集中式在权限、二进制、易用性、备份等方面有切实优势。
unpopular opinion：我们在一个大项目上用 SVN，没打算换。原因：1) 与 AD 集成，220 人使用时能确定“谁干的”；2) 支持部分检出，我们的平台有 600 万行代码；3) TortoiseSVN 无可替代；4) 二进制文件和锁定机制适合设计流程；5) 集中式意味着单一事实来源；6) 备份和复制简单（svndump/svnsync）；7) 凭借集中化和 hook 支持与工具链完美集成；8) 普通人（用 Excel/Word 的人）也容易上手；9) 强制备份行为——曾有人本地用 git 但没推送，SSD 一坏就丢了一周的工作。合并追踪自 1.7 起不是问题，需要离线就打补丁。8 年来我们的 SVN 只宕机过 3 分钟。
cssmoo查看英文原文
Unpopular opinion here but we're using SVN here on a large project. No intention of changing it. Why? 1. Deterministic "whodunnit" as we have AD integrated with. That is needed when you have 220 people using a repo. 2. Partial check outs. Our platform is 6MLoC in total. 3. TortoiseSVN. Sorry there's nothing else out there as good as that. We use it for DMS tasks as well as you can merge word docs etc. 4. Binaries and locking. Works for design workflows and the odd file we can't merge easily (git/mercurial aren't magic bullets for that). 5. Centralised. All our shit is in one place so there's a "single source of truth". Also no patches flying around. 6. Easy to backup and replicate. Svndump into single file. Or svnsync and there's a true copy. 7. Perfect tooling/tracking integration due to the centralisation and hook support. 8. Easy to use for mere mortals (excel/word pokers). 9. Forces backup behaviour. A specific case but we had a couple of people using git and then pushing to our svn. One SSD fail and bang, the guy lost a week of work because he didn't push to master. Merge tracking is a non issue since 1.7 and if you need to work offline, just create patches and check them in when you're back online. Also our svn instance has been down for 3 minutes in the last 8 years... I really can't justify a move to a DVCS and lose all the above so I'm quite happy with my sanity.
以 Linux 内核为例说明：对某些超大规模分布式项目，DVCS 的分布式特性是刚需。
作为 Linux 内核开发者——Git 最初就是为这个项目设计的——我建议大家看看内核的工作流，体会 Git 从何而来，这是一个 D（分布式）极其关键的项目。我们有约 2000 万行代码、巨大的仓库（我本地副本 2.8GB）、高度分布式的协作（我本地有 17 个 remote、40 个本地分支）……而我们仍然用邮件列表补丁和 pull request，不用 submodule，也不把 GitHub 当作 git 服务器之外的东西。一切基本运转良好……这与 GitHub 上普通项目的工作方式形成了有趣的对比。
rossy查看英文原文
My number one favourite thing about Git is that is that I have a full copy of the repository history and I can work on it without talking to a central server, or any server. I can do a `git blame` or a `git bisect` without receiving a byte from the network, which is great because my internet connection is horrible. I can work on a train. I can work on an experimental feature in a branch with full history, decide it was a bad idea, delete the branch, and no one has to know about my failure. I can even share that branch between multiple machines in my house without setting up any server infrastructure. I can write shitty commit messages like 'fix the thing for real this time' and clean them up later with a rebase before I push. I can make a series of commits, convert them to a series of patches and apply them during a build script with `git am`. I can version any folder on my machine just by typing `git init`, which is especially useful for folders of config files. Also, I think Git's model of working locally encourages people to think of their commits like their code. Good Git projects have small commits, a clean history and commit messages that are like documentation (which is especially useful, because you can use blame to locally find the change relating to a line.)
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选