5 ms·

You mean as hard as when Git obliterated every other VCS within the span of a few years? If products are better, they get adopted. How do you think every single

by axlee 4y ago

You mean as hard as when Git obliterated every other VCS within the span of a few years? If products are better, they get adopted. How do you think every single company in the world started to develop for iOS between 2008 and 2010? When the upside is obvious and the path to transition is well-defined, there is very little friction.

wizofaus 4y ago
I still don't understand how git won the source control battle so decisively. I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops. JIRA I can take or leave, it does the job - it's hard to imagine anyone being driven to hate it, but I can believe having it badly configured would be a serious drain on productivity.
- ecuzzillo 4y ago
  I can only speak to the comparison with hg, but for large repos, git's performance is literally 10x better in our case (we have two parallel copies, one in hg and one in git, so as to smooth the transition to git). hg seems more usable, but certain decisions are poor (e.g. baking the branch name into each commit); overall I have no strong preference between the two except for the speed. But the speed pretty much drowns out any other signal.
  - snapetom 4y ago
    git's performance increase came around at the right time, too. Code bases were becoming bigger and bigger, and Agile's popularity preached a lot of branching. SVN branches were a full copy, making things way worse.
    - wizofaus 4y ago
      Yeah that had occurred to me. But I'd used TFS (which didn't have light-weight branches) with Agile-like development practices and it wasn't that big a deal. Maybe if the codebase was 10 or 20 times bigger it would've been.
- dijit 4y ago
  Migration was easy, it was decentralised, had a famous original author & a huge famous project using it and had a lot of "hip" source code platforms such as github, gitorious, bitbucket (pre-atlassian) and gitlab. I'm not surprised it won tbh. Game companies are still using Perforce though.
  - andybak 4y ago
    > Game companies are still using Perforce though. Maybe the ratio of text to non-text assets?
    - jdougan 4y ago
      That, and repo size can get huge in a game project and no one wants to have to copy the whole thing to do a check out. Svn still sees use for gamedevs that don't want to buy.
- MaxBarraclough 4y ago
  > I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops. At this point git is the incumbent, which is self-sustaining: developers already know git, so you'd need a really compelling reason to use anything else and take on the burden of training your developers to use it. It helps that git is freely available and is by far the top choice for Free and Open Source projects. Of course, SVN used to be in the same position, but git is such a great improvement that it was able to win out. I imagine git's origins in Linux kernel development may also have been a factor in its early success.
cogman10 4y ago
> You mean as hard as when Git obliterated every other VCS within the span of a few years There's not a concept impedance mismatch going from CVS->SVN->GIT. The concepts are so similar that git-svn exists to convert a SVN repo into a git repo (and a similar conversion tool exists for CVS->SVN) Jira is so flexible and configurable that no such tool could exist. Migrating to a new tracking system requires that you either lose all currently tracked issues and their history OR you spend the money and effort handcrafting for your org a Jira->Foo translator to preserve some semblance of history. The larger and more diverse the org, the harder such a tool will be to craft. > How do you think every single company in the world started to develop for iOS between 2008 and 2010? Because ignoring a company that commands 30% of the market is a bad idea? How do you explain the flop of WebOS which was, IMO, a far better UX and OS compared to either IOS or Android?
- axlee 4y ago
  How about when every single company rewrote their frontend stack in React after angular.js was done, circa 2015? Or when everyone moved to k8s within 2 years around 2017-2019? Hell, now even companies that definitely wouldn't benefit from anything related to k8s are diving into it. What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. Yarn got adopted within a year above npm, the "default node package manager". Everything is always up for grabs, if you can show the benefits, however small they are. And the history aspect of Jira isn't an unsolvable problem, pretty much every single issue tracker in the world offers a Jira import, and losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. If a company can show that their alternative to Jira solves a percentage of common complaints against Jira, while offering the same capabilities of scaling that Jira does, people will follow. Nobody wants to deal with crappy products. Especially since the ones suffering the most from Jira are usually the ones in charge of setting up the very processes that Jira is supposed to help with, and to procure the tooling.
  - cogman10 4y ago
    > How about when every single company rewrote their frontend stack in React God I wish that were the case. My company is still rocking Angular unfortunately :( > Or when everyone moved to k8s within 2 years around 2017-2019 That did not happen. k8s got a good share of the market, but it's far from "everyone moved". > What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. The tools you are listing are all dev tools picked, used, and curated by development. Jira isn't a dev tool, it's a product management tool. There's a major difference between tools that devs can pick and choose and tools that an organization gets to pick and choose. Even with your "yarn" example, while it took over it didn't replace "npmjs" as the centralized repository server. Just like gradle still gets it's artifacts primarily from maven central. I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written? Why does it remain one of the most popular programming languages even though most people are VERY quick to point out it's major flaws. Even though other better alternatives exist (Rust, Nim, D, etc). > losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. Assuming you like everyone else went from svn->git I don't see how you'd have lost commit history. I personally converted a BUNCH of repos to git and didn't see any cases of lost history.

by axlee 4y ago

wizofaus 4y ago

I still don't understand how git won the source control battle so decisively. I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops. JIRA I can take or leave, it does the job - it's hard to imagine anyone being driven to hate it, but I can believe having it badly configured would be a serious drain on productivity.

ecuzzillo 4y ago
I can only speak to the comparison with hg, but for large repos, git's performance is literally 10x better in our case (we have two parallel copies, one in hg and one in git, so as to smooth the transition to git). hg seems more usable, but certain decisions are poor (e.g. baking the branch name into each commit); overall I have no strong preference between the two except for the speed. But the speed pretty much drowns out any other signal.
- snapetom 4y ago
  git's performance increase came around at the right time, too. Code bases were becoming bigger and bigger, and Agile's popularity preached a lot of branching. SVN branches were a full copy, making things way worse.
  - wizofaus 4y ago
    Yeah that had occurred to me. But I'd used TFS (which didn't have light-weight branches) with Agile-like development practices and it wasn't that big a deal. Maybe if the codebase was 10 or 20 times bigger it would've been.
dijit 4y ago
Migration was easy, it was decentralised, had a famous original author & a huge famous project using it and had a lot of "hip" source code platforms such as github, gitorious, bitbucket (pre-atlassian) and gitlab. I'm not surprised it won tbh. Game companies are still using Perforce though.
- andybak 4y ago
  > Game companies are still using Perforce though. Maybe the ratio of text to non-text assets?
  - jdougan 4y ago
    That, and repo size can get huge in a game project and no one wants to have to copy the whole thing to do a check out. Svn still sees use for gamedevs that don't want to buy.
MaxBarraclough 4y ago
> I respect git for what it's good at and its power, but from what I've observed it's far from clearly being the obvious choice of source control for closed source software shops. At this point git is the incumbent, which is self-sustaining: developers already know git, so you'd need a really compelling reason to use anything else and take on the burden of training your developers to use it. It helps that git is freely available and is by far the top choice for Free and Open Source projects. Of course, SVN used to be in the same position, but git is such a great improvement that it was able to win out. I imagine git's origins in Linux kernel development may also have been a factor in its early success.

cogman10 4y ago

> You mean as hard as when Git obliterated every other VCS within the span of a few years There's not a concept impedance mismatch going from CVS->SVN->GIT. The concepts are so similar that git-svn exists to convert a SVN repo into a git repo (and a similar conversion tool exists for CVS->SVN) Jira is so flexible and configurable that no such tool could exist. Migrating to a new tracking system requires that you either lose all currently tracked issues and their history OR you spend the money and effort handcrafting for your org a Jira->Foo translator to preserve some semblance of history. The larger and more diverse the org, the harder such a tool will be to craft. > How do you think every single company in the world started to develop for iOS between 2008 and 2010? Because ignoring a company that commands 30% of the market is a bad idea? How do you explain the flop of WebOS which was, IMO, a far better UX and OS compared to either IOS or Android?

axlee 4y ago
How about when every single company rewrote their frontend stack in React after angular.js was done, circa 2015? Or when everyone moved to k8s within 2 years around 2017-2019? Hell, now even companies that definitely wouldn't benefit from anything related to k8s are diving into it. What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. Yarn got adopted within a year above npm, the "default node package manager". Everything is always up for grabs, if you can show the benefits, however small they are. And the history aspect of Jira isn't an unsolvable problem, pretty much every single issue tracker in the world offers a Jira import, and losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. If a company can show that their alternative to Jira solves a percentage of common complaints against Jira, while offering the same capabilities of scaling that Jira does, people will follow. Nobody wants to deal with crappy products. Especially since the ones suffering the most from Jira are usually the ones in charge of setting up the very processes that Jira is supposed to help with, and to procure the tooling.
- cogman10 4y ago
  > How about when every single company rewrote their frontend stack in React God I wish that were the case. My company is still rocking Angular unfortunately :( > Or when everyone moved to k8s within 2 years around 2017-2019 That did not happen. k8s got a good share of the market, but it's far from "everyone moved". > What I am trying to show by these examples is that things can move fast, very fast, and that in our industry there are no such thing as well-entrenched tools. The tools you are listing are all dev tools picked, used, and curated by development. Jira isn't a dev tool, it's a product management tool. There's a major difference between tools that devs can pick and choose and tools that an organization gets to pick and choose. Even with your "yarn" example, while it took over it didn't replace "npmjs" as the centralized repository server. Just like gradle still gets it's artifacts primarily from maven central. I'll go back to something I said elsewhere. If it's so easy to move and change why is C++ still being written? Why does it remain one of the most popular programming languages even though most people are VERY quick to point out it's major flaws. Even though other better alternatives exist (Rust, Nim, D, etc). > losing issue history is far less damaging than it was losing "commit" history when everyone was moving to git back in the days. Assuming you like everyone else went from svn->git I don't see how you'd have lost commit history. I personally converted a BUNCH of repos to git and didn't see any cases of lost history.