[nailer]

I think sometimes we forget that network effects outweigh most normal values of technical superiority. Let's say, for the purposes of the argument, that "hg/Mercurial is 20% better than git".

This doesn't matter: hg/Mercurial has to be 500% better than git to be able to replace it.

Look at the past changes: they've all been huge shifts in how we do version control, not minor improvements

The DVCSs were 500% better than Subversion (wow, distributed!)

Subversion was 500% better than CVS (wow, renames work! Branching is easy! http support!)

CVS was 500% better than RCS (wow, we can check out files concurrently)

[threeseed]

You are right. But it is often referred to as the 10x rule.

http://www.minidisc.org/econ113-paper.htm

A technology needs to be 10x better than a previous one for widespread adoption. It has successfully explained many failed technologies and products.

[kazinator]

> A technology needs to be 10x better than a previous one for widespread adoption. It has successfully explained many failed technologies and products.

A hypothesis about failure, on the other hand, has to account for the failures and successes. This one doesn't. While it can plausibly explain failed technologies and products, it doesn't explain the historic success of junk that is worse than its predecessors.

A technology can be hyped into widespread adoption. It can be dumped on the market for widespread adoption. It can ride on top of cheap hardware for widespread adoption. It can be bundled with something else, achieving widespread adoption. A technology can be falsely evaluated as 10X better by a large number of complete idiots, resulting in widespread adoption among idiots, resulting in pressure for non-idiots to adopt.

All these effects can overcome the barrier of having to be actually, objectively 10X better. The "10X better adoption barrier" is only faced by honestly promoted technologies whose campaign consists of "try this because it's better for these objective reasons".

[0x0]

"Better" can mean a lot of things including "cheaper", "easier to use", "better marketed", etc. Explains why sometimes "worse is better", I think :)

[kazinator]

Yes; "worse is better" rings true when the "worse" on the left hand side is the antonym of a different meaning of "better" from the right hand side "better"; i.e. an equivocation on the word is going on (not to deceive but to create a play on words).

[kazinator]

That's not really a "network effect", but more of an "activation potential barrier". If it cost almost nothing to migrate to a new system, then 5% better might be a good enough reason. If I'm going to do back-end setup, data migration and re-train myself and others, then, damn it, I demand a 500% improvement to show for it. :)

[dredmorbius]

It's a network effect.

If you're going to attract new contributors to a system, having the toolset that everyone else uses is a huge win.

I've been at this long enough to have learned (somewhat) each of RCS, CVS, SVN hg, and git. In the beginning there were (mostly) just two: RCS and SCCS, and nobody used SCCS. With time, I've touched several others, had to wrap my head around them, as additional challenges to getting my primary job done, which generally involved solving problems in other domains (or learning other tool).

And ... some of that's knowledge which has stuck, some isn't. The time invested in learning is sunk cost, though there's the problem that it all leaves traces on your brain.

This is something that 20-somethings don't get: it's not learning things so much as unlearning. It's one thing to launch into a field with the hot new technology under your belt. I landed with some awarness of Unix when that was fairly unusual, and parlayed that and a set of tools for 25 years. During which I've not stood still...

... but the rate at which new tools are introduced, and having to sort out which actually will win is a considerable overhead. After a while it ... just gets kind of old. Especially since you realize that all of it is a constructed complexity, largely arbitrary.

How many operating systems (7, not counting Unix variants), shells (9), editors (10+), scripting languages (8), database implementations (7), firewall systems (4), webservers / application engines (6), mailservers (6), document markup languages (6+), etc., etc., etc., do you want to learn over your lifetime? Some are pretty cool. Others ... are just makework.

This spills over to larger highly integrated stuff which previous experience shows is almost always going to be a massive clusterfuck, of which I'll not mention systemd by name.

Which means you want to consider what projects you work on, where you work, etc. Google have a challenge in this regard with their NIH model -- work at Google long enough and you'll learn some really cool, advanced technology. Which nobody, anywhere else, uses. And, no, they're not the only ones. But they definitely come to mind.

[rleigh]

The unlearning point is definitely true. After using CVS for many years, Arch and then git were conceptually difficult to get into, and I was an early adopter of both. Not because they are actually difficult, but because your years of understanding of "how version control works" simply doesn't map onto the new way of doing things.

The last few weeks, after using git for a decade now I guess, I had to use CVS to checkout and contribute some changes to a project still using CVS. Wow, was that painful! One does get used to the simplicty and features of git, and going backward to older tools makes one really appreciate what they give you.

[pjmlp]

How I share your thoughts.

Been in the industry since the late 80's. Eventually one gets tired of listening to every single fad.

[davidgerard]

> ... but the rate at which new tools are introduced, and having to sort out which actually will win is a considerable overhead. After a while it ... just gets kind of old. Especially since you realize that all of it is a constructed complexity, largely arbitrary.

One of the most important parts of my job as a sysadmin is the immediate sniff test on trendy technology of the week and being able to spot the obvious pain points early. Bitter experience, it's useful!

[dredmorbius]

Quite. Though it's less the sniff tests and more the banishment from workplaces / sites / tools I use that get to be draining. Again: systemd. Which risks fucking over an entire massive (and otherwise highly useful) resource.

[davidgerard]

The systemd battle's a lost cause I think. Pity, 'cos upstart was a reasonable implementation of the concept and vastly superior to init shell scripts. At least it's not Windows Server.

(TODO: pointy-clicky interface to systemd)

[JdeBP]

Would that be along the lines of https://packages.debian.org/sid/systemd-ui , https://projects.kde.org/projects/playground/sysadmin/system... , or https://forum.manjaro.org/index.php?topic=272.0 ?

[digi_owl]

Could have sworn i have already seen a early version of such a interface for either KDE or Gnome...

[digi_owl]

And why MS products stick around (and people bellyache when changes are made to the UI).

[dredmorbius]

I've become exceptionally leery of GUIs for anything remotely complex. Scripting provides the kick in the ass incentive not to arbitrarily utterly bollox interactions as countless millions of scripts would have to be rewritten. You end up with stuff like Sendmail compatible commands and switches for mailers long since the former's heyday (qmail a notable exception). Or SSH and rsh being largely compatible.

On the rare cases syntax does change people raise holy hell. It can kill tools. Especially if done more than once.

GUIs have none of these features and change capriciously.This tends to keep user proficiency at a low general level over time.

Web apps only extend this.

[david-given]

I use hg as a front end to git, so I get the advantages of git's mindshare without having to deal with git's UI. Now I get the best of both worlds.

[krupan]

If I ever am forced to use git I'm hoping I can do this. Does it work well? I'm being forced to use svn right now at work and hgsubversion is a little rough around the edges.

[david-given]

Really well. The one stumbling block is that git branches are mapped on to hg bookmarks, and it's not quite seamless --- I haven't figured out all the subtleties yet, but it doesn't seem to get bookmark deletion right, for example (the bookmark will reappear the next time you do an hg pull).

I use github as a backend, so I tend to do branch manipulation using the github UI, so this isn't an issue for me.

Everything else Just Works. Highly recommended.

[vezzy-fnord]

(wow, distributed!)

With the ultimate irony that people largely use it in a centralized fashion.

[kazinator]

Distributed doesn't mean decentralized; they are not synonyms.

DNS is distributed, yet it has a "root" servers.

Even if there a master repository in a given git scenario, it is still distributed because developers have their own repositories, which are independent, and contain a replica of the copies of the upstream objects.

[vezzy-fnord]

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.

[sampo]

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

[kelnos]

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.

[comex]

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

[skeeterbug]

A central origin sure. It is nice knowing I can work offline which is my general workflow. I can also experiment with local branches and not push them to a remote.

[Manishearth]

Do people work on the same files/folders at the same time? Then the workflow is already way more distributed than svn ever was :)

[ams6110]

We did that in svn all the time with few issues.

[ngoldbaum]

Might changeset evolution [1] (e.g. safe collaborative rewriting of public history) be that 500% bonus?

[1] https://mercurial.selenic.com/wiki/ChangesetEvolution

[rbehrends]

Changeset evolution is conceptually brilliant [1], but I suspect that it's really something that only a few percent of VCS users will actually use (at least beyond the level of features that Mercurial and Git already support).

[1] ... in that it provides not just safe mutable history, but shared mutable history.

[ionforce]

It's like the coefficient of friction.

The amount of force required to move an object at rest is greater than the amount of force required to maintain it already moving (or something like that).

[octo_t]

> Branching is easy

when svn first came out (and up until a few years ago) branching was definitely not easy!

[lfowles]

What changed a few years ago?

[anonydsfsfs]

Subversion 1.5 added support for tracking merges: https://subversion.apache.org/docs/release-notes/1.5.html#me...

Before this, merging branches was a huge pain, because you had to manually keep track of the commits that needed to be merged.