Comment

Comment by 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.

parent iand675 11 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton