It was painfully difficult to branch in subversion. And remember the agony of asking someone to check in a file so another developer can check it out?

Branching was just a copy? What was so hard about that?

As for check-out locks. you only had to ask them to do that if they'd requested a lock on the file which was not the default. I hope people weren't doing that too often at your workplace.

To be fair, Subversion had plenty of serious limitations. Local commits are a really good thing. It's just that Git itself is a terrible UI around a bunch of decent ideas.

Sure. Absolutely but there were some benefits to its simple model that are still attractive for a corporate env.

https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...

One of my fav rants on this subject.

Merging is an operation which takes three inputs: left, right, and common ancestor. This is a very old algorithm, the diff3 utility on Unix is at least from the 70s I think? The reason history is a graph is to walk the graph and find common ancestors. Subversion's model cannot do this (screw off, pedants, I know they added an attempt at detecting common ancestors after Git had long since supplanted Subversion in relevance).

And if you can't merge, you can't branch. And if you can't branch, you need locks.

I'm just saying, as someone who has used subversion quite a lot over the years, the situation he is describing where you have an exclusive lock where they have to check in before you can, does not happen. Exclusive locks are very rarely used in subversion. If you and your coworker are working on a file, and he checks in before you, you will simply have to update and merge. Similar to if you were both working on a local git or mercurial tree.

Oh, and in that situation the 3 way merge is between the version he checked into the repo, your local version you are trying to commit, and your parent revision.

Well put! And it demonstrates why people (like the HN'ers who think they're 10xers) have trouble with git. They fundamentally don't understand the problem and how git solves it.

This is correct, and yet Git is an embarrassment to our profession. That's how bad it is.