4 ms·

Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev rea

Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.

fortran77 4y ago
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?
- capitainenemo 4y ago
  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.
  - howinteresting 4y ago
    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.
    - capitainenemo 4y ago
      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-and-return-to-sanity/ https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs... One of my fav rants on this subject.
  - juped 4y ago
    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.
    - capitainenemo 4y ago
      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.
      - capitainenemo 4y ago
        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.
    - fortran77 4y ago
      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.
    - howinteresting 4y ago
      This is correct, and yet Git is an embarrassment to our profession. That's how bad it is.

Finally someone comes out and says it - I totally agree. I don't recall ever having to have a "tutorial" on Subversion. Git solves a problem the average dev really doesn't have in the first place.

fortran77 4y ago

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?

capitainenemo 4y ago
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.
- howinteresting 4y ago
  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.
  - capitainenemo 4y ago
    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-and-return-to-sanity/ https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs... One of my fav rants on this subject.
- juped 4y ago
  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.
  - capitainenemo 4y ago
    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.
    - capitainenemo 4y ago
      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.
  - fortran77 4y ago
    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.
  - howinteresting 4y ago
    This is correct, and yet Git is an embarrassment to our profession. That's how bad it is.