Hacker News new | ask | show | jobs
by vezzy-fnord 3953 days ago
The point is that at least for a VCS, centralization does largely subvert the distributed aspect. At that point, you no longer really have multiple repositories so much as multiple working copies, similar to a CVCS. Your work model revolves around a blatant SPOF which you must synchronize all changes to.

The Linux kernel is a proper example of distributed workflow.
2 comments
sampo 3952 days ago
According to this text by Joel Spolsky, in SVN-days developers spent days and days massaging code but not committing, because committing meant pushing to the central repository public to everyone. With git/hg developers can use version control also in their incremental daily work, and finally merge or rebase or squash or whatever, to massage their work into a form that is good for pushing to the master.

http://hginit.com/00.html

link
kelnos 3953 days ago
That depends on what you want out of the "distributed" aspect. If all you care about is offline access to the repo, and like the fact that everyone's checkout is effectively a backup of what's on the central server, then centralization doesn't really take away from the distributed nature.

Even if you consider the SPOF-y nature of something like GitHub, more savvy git users will realize that if GitHub was down for an extended period of time, they could push their repo somewhere else that's public, like Bitbucket, or their own server, and keep working and allowing other people to collaborate. And for shorter downtime of the central server (where you might feel like setting up an alternate is too much effort), everyone can still get work done, they just can't collaborate as effectively until things are restored.

link
comex 3952 days ago
That works for the repo, but not issues, pull requests, wiki pages, permissions, or any other services GitHub provides. None of those work offline, and while there is an API that can help with migration, doing so still requires setting up a totally different system, and there is no natural backup on every developer's machine like with the repo - you have to do it manually while the origin is still up. (Not that GitHub is likely to disappear anytime soon, but all things will end someday.) Which is unfortunate because it seems like a missed opportunity: it's certainly possible to implement all those things in a decentralized manner, and some projects have tried, but so far with little success...
link