5 ms·

Up to 2011 I used Subversion. Then I worked for a year for a company that used CVS. So, by comparison, my time with Subversion looks trouble-free, as you can im

Up to 2011 I used Subversion. Then I worked for a year for a company that used CVS. So, by comparison, my time with Subversion looks trouble-free, as you can imagine. I've worked in Git ever since, but every time Git makes my feet hurt, I think back with fond memories to Subversion and TortoiseSVN, probably unwarranted so.

TylerE 3y ago
Don’t even have to go that far back. Mercurial is/was a way better ux over a very similar feature set.
- paulddraper 3y ago
  I wonder why mercurial didn't win. I think it was the performance.
  - nordsieck 3y ago
    IMO, it really helped that Linux/Linus had a lot more fame. At the time there was drama around Bitkeeper, which Linux found acceptable, but was closed source.
  - HWR_14 3y ago
    Mercurial was optimized for performance on windows. On other OSes it was worse. But the reason it didn't win isn't that. It was GitHub. GitHub changed it from "use one of several analogous products"[0] to network effects. [0] Joel, founder of StackOverflow, had a GitHub like competitor that used either git or mercurial commands on the same repository. Just as one example of how similar they are.
    - paulddraper 3y ago
      But bitbucket supported both
      - jholman 3y ago
        And (approximately) no one ever cared.
  - dilyevsky 3y ago
    Mercurial is 30% faster than git… to type. Imo it didn’t win bc git was cooler because kernel
  - madisp 3y ago
    For me it definitely was performance. 5 years ago or so I ended up using a mercurial-git bridge just to use git on a team where everyone was on hg. IIRC git grep search took seconds compared to more than a minute with hg grep.
  - flohofwoe 3y ago
    > I wonder why mercurial didn't win. Because it's called Github, not Mercurialhub ;) (I bet if Github would have chosen Mercurial instead, the popularity would be reversed, at the time I switched to Github I was just looking for an alternative to SourceForge for hosting my open source stuff, but didn't care much about the actual version control system).
  - lucideer 3y ago
    I don't think most people really care that much about performance; rather a vocal minority. Most devs are not that discerning in choosing their tools: they'll happily use what's given to them or what's mainstream when they're learning and stick with it as long as they can. This is the quiet (massive) majority that mostly don't post on HN. I see a lot of people attributing Git's "win" to GitHub, and that's likely the biggest nail in the coffin, but the GH devs chose it because it was already reasonably popular and it was popular because of Linus Torvalds.
  - WorldMaker 3y ago
    I think one of the answer's is sadly just: Mercurial was written in Python. Regardless of what the benchmarked real-world performance of Mercurial was or how well optimized it was, there is a class of developer that thinks all Python is slow and may never change their mind about it. Python seemed a good decision: git had a two week headstart and Mercurial was faster to hit many usability milestones (and arguably git may never hit some of them, jk). Mercurial had good Windows support from early on (and doesn't need to ship like half of the GNU userland to do it). I just don't think it should be surprising that some Linux kernel developers dismissed Mercurial off-hand just for being written in Python. I also don't think it is a coincidence that early GitHub ignored Mercurial just about as dismissively. (Ruby and Python aren't entirely "competitors" but there isn't always a lot of shared love between them.)
    - paulddraper 3y ago
      And (a lot of) Git was implemented with Bash scripts. Whether it was the language or not, Mercurial was objectively slower than Git. Nowadays that doesn't matter much, but 15 years ago, it was a much different story.
      - WorldMaker 3y ago
        The "core" (most of the "plumbing") was always C/C++ and most of those bash scripts (with very few Perl exceptions) were automating GNU C/C++ tools. I've certainly referred to git as a Frankenstein's monster of shell scripts myself, but the sorts of developers that hate Python often don't seem to see bash scripts, they see lots of little invocations of C/C++ tools and "C/C++ core" matters to them. (They also tend to get irrationally angry when you challenge that logic and point out what the C in CPython, the most common Python runtime, stands for.) > Whether it was the language or not, Mercurial was objectively slower than Git. That was not my experience, but I was on Windows at the time. Mercurial "objectively" had good Windows performance. (Not just because it ran at all, versus how much work it took to tame Frankenstein's Monster of shell scripts that was early git to run at all on Windows. But also because it's file system transaction model always fit Windows better.) (ETA: Also, to be fair, my "team" at the time was darcs and my opinions on VCS performance at the time were from a very different perspective.)
- jimmaswell 3y ago
  I use Mercurial on a volunteer project and it gives me problem after problem including repository corruptions and it's extremely slow for the same things git does before I can blink. I often wish it never existed so our team was never tempted to try it over industry standard git. Everything integrates with git, git is optimized every day by devs all over the world, every issue you can have with git is on stackoverflow, and it's essentially bug-free, meanwhile mercurial is some niche thing with embarrassing bugs written in python. It's especially vexing that mercurial throws a fit if you try to do anything like pull with changes in your repository while git does the sensible thing and just works.
- seba_dos1 3y ago
  I have used Mercurial at work for a few years about a decade ago after already knowing git basics (but only basics back then). It never felt "better" or "worse" to me, it was just a slightly different git. Its branch handling was a bit confusing compared to git's, but it was manageable. One thing that perhaps let me understand git better later was how `hg pull` works actually like `git fetch` and makes more sense than `git pull`. The team has eventually switched to git anyway.
CivBase 3y ago
I started with Git and now work with Subversion. SVN is definitely simpler but I find myself regularly getting frustrated with its relative lack of features and the wait times inherant to centralized version control systems. If I could go back to Git I would in a heartbeat.
- gorgoiler 3y ago
  You have two options. You can use the git-svn bridge or manage your own patches. git-svn has a lot of good features that are specific to it, so it’s worth learning it like a new tool rather than a git feature. Get comfortable with it from some tutorials, then read the man page from top to bottom. It’s worth it. The cheapo version is to git init and checkout of your source code, pretend it’s a git project, and then produce a patch for your branch at the end. You might even be able to use svn and git commands in the same directory? git for managing your private “work in progress” branches, locally, and svn to track upstream and submit work.
ozim 3y ago
I have exactly opposite experience with Subversion and Tortoise Git from pre 2011. For me it was annoying and janky any conflicts were blocking me for ages. With git it’s a breeze and I would never ever want to go back.
e12e 3y ago
It's not quite fair to compare Distributed VCS to strictly centralized IMNHO (even if a lot of people are using git as a centralized VCS with GitHub in the middle). Still, it is interesting to compare workflows and common gotchas.
thiht 3y ago
Subversion was atrocious. Not having a proper staging area was a nightmare to work with.

TylerE 3y ago

Don’t even have to go that far back. Mercurial is/was a way better ux over a very similar feature set.

paulddraper 3y ago
I wonder why mercurial didn't win. I think it was the performance.
- nordsieck 3y ago
  IMO, it really helped that Linux/Linus had a lot more fame. At the time there was drama around Bitkeeper, which Linux found acceptable, but was closed source.
- HWR_14 3y ago
  Mercurial was optimized for performance on windows. On other OSes it was worse. But the reason it didn't win isn't that. It was GitHub. GitHub changed it from "use one of several analogous products"[0] to network effects. [0] Joel, founder of StackOverflow, had a GitHub like competitor that used either git or mercurial commands on the same repository. Just as one example of how similar they are.
  - paulddraper 3y ago
    But bitbucket supported both
    - jholman 3y ago
      And (approximately) no one ever cared.
- dilyevsky 3y ago
  Mercurial is 30% faster than git… to type. Imo it didn’t win bc git was cooler because kernel
- madisp 3y ago
  For me it definitely was performance. 5 years ago or so I ended up using a mercurial-git bridge just to use git on a team where everyone was on hg. IIRC git grep search took seconds compared to more than a minute with hg grep.
- flohofwoe 3y ago
  > I wonder why mercurial didn't win. Because it's called Github, not Mercurialhub ;) (I bet if Github would have chosen Mercurial instead, the popularity would be reversed, at the time I switched to Github I was just looking for an alternative to SourceForge for hosting my open source stuff, but didn't care much about the actual version control system).
- lucideer 3y ago
  I don't think most people really care that much about performance; rather a vocal minority. Most devs are not that discerning in choosing their tools: they'll happily use what's given to them or what's mainstream when they're learning and stick with it as long as they can. This is the quiet (massive) majority that mostly don't post on HN. I see a lot of people attributing Git's "win" to GitHub, and that's likely the biggest nail in the coffin, but the GH devs chose it because it was already reasonably popular and it was popular because of Linus Torvalds.
- WorldMaker 3y ago
  I think one of the answer's is sadly just: Mercurial was written in Python. Regardless of what the benchmarked real-world performance of Mercurial was or how well optimized it was, there is a class of developer that thinks all Python is slow and may never change their mind about it. Python seemed a good decision: git had a two week headstart and Mercurial was faster to hit many usability milestones (and arguably git may never hit some of them, jk). Mercurial had good Windows support from early on (and doesn't need to ship like half of the GNU userland to do it). I just don't think it should be surprising that some Linux kernel developers dismissed Mercurial off-hand just for being written in Python. I also don't think it is a coincidence that early GitHub ignored Mercurial just about as dismissively. (Ruby and Python aren't entirely "competitors" but there isn't always a lot of shared love between them.)
  - paulddraper 3y ago
    And (a lot of) Git was implemented with Bash scripts. Whether it was the language or not, Mercurial was objectively slower than Git. Nowadays that doesn't matter much, but 15 years ago, it was a much different story.
    - WorldMaker 3y ago
      The "core" (most of the "plumbing") was always C/C++ and most of those bash scripts (with very few Perl exceptions) were automating GNU C/C++ tools. I've certainly referred to git as a Frankenstein's monster of shell scripts myself, but the sorts of developers that hate Python often don't seem to see bash scripts, they see lots of little invocations of C/C++ tools and "C/C++ core" matters to them. (They also tend to get irrationally angry when you challenge that logic and point out what the C in CPython, the most common Python runtime, stands for.) > Whether it was the language or not, Mercurial was objectively slower than Git. That was not my experience, but I was on Windows at the time. Mercurial "objectively" had good Windows performance. (Not just because it ran at all, versus how much work it took to tame Frankenstein's Monster of shell scripts that was early git to run at all on Windows. But also because it's file system transaction model always fit Windows better.) (ETA: Also, to be fair, my "team" at the time was darcs and my opinions on VCS performance at the time were from a very different perspective.)
jimmaswell 3y ago
I use Mercurial on a volunteer project and it gives me problem after problem including repository corruptions and it's extremely slow for the same things git does before I can blink. I often wish it never existed so our team was never tempted to try it over industry standard git. Everything integrates with git, git is optimized every day by devs all over the world, every issue you can have with git is on stackoverflow, and it's essentially bug-free, meanwhile mercurial is some niche thing with embarrassing bugs written in python. It's especially vexing that mercurial throws a fit if you try to do anything like pull with changes in your repository while git does the sensible thing and just works.
seba_dos1 3y ago
I have used Mercurial at work for a few years about a decade ago after already knowing git basics (but only basics back then). It never felt "better" or "worse" to me, it was just a slightly different git. Its branch handling was a bit confusing compared to git's, but it was manageable. One thing that perhaps let me understand git better later was how `hg pull` works actually like `git fetch` and makes more sense than `git pull`. The team has eventually switched to git anyway.

CivBase 3y ago

I started with Git and now work with Subversion. SVN is definitely simpler but I find myself regularly getting frustrated with its relative lack of features and the wait times inherant to centralized version control systems. If I could go back to Git I would in a heartbeat.

gorgoiler 3y ago
You have two options. You can use the git-svn bridge or manage your own patches. git-svn has a lot of good features that are specific to it, so it’s worth learning it like a new tool rather than a git feature. Get comfortable with it from some tutorials, then read the man page from top to bottom. It’s worth it. The cheapo version is to git init and checkout of your source code, pretend it’s a git project, and then produce a patch for your branch at the end. You might even be able to use svn and git commands in the same directory? git for managing your private “work in progress” branches, locally, and svn to track upstream and submit work.

ozim 3y ago

I have exactly opposite experience with Subversion and Tortoise Git from pre 2011. For me it was annoying and janky any conflicts were blocking me for ages. With git it’s a breeze and I would never ever want to go back.

e12e 3y ago

It's not quite fair to compare Distributed VCS to strictly centralized IMNHO (even if a lot of people are using git as a centralized VCS with GitHub in the middle). Still, it is interesting to compare workflows and common gotchas.

thiht 3y ago

Subversion was atrocious. Not having a proper staging area was a nightmare to work with.