Ask HN: Can anything make Git as popular as Subversion? | Hacker News Reader

Ask HN: Can anything make Git as popular as Subversion?

11 pointslkrubner16 comments

I recall when git caught on, during the era 2010-2012. From 2005-2012 the companies I worked at used Subversion, but since late 2012, every company I've been at has used git. I used to ask, "Will it be possible for everyone on the team to use this?" and most proponents of git said "Eventually we will develop easy GUIs so everyone can use it" but it's been more than 10 years now and it still hasn't happened. git is popular with computer programmers, and it is only popular with computer programmers. I recall at the companies that used Subversion, it was the universal version control for everyone at the company: the CEO, the CFO, the graphic designers, the marketing team, the sales team -- anyone who had a document they wanted to save or share, they would just throw it into Subversion. On Windows, there was the TortoiseSVN client, which many people felt something akin to joy when they used.

I was concerned when git emerged because suddenly these organizations were riven across multiple version control systems. The CEO, the CFO, the graphic designers, the marketing team -- all of these people started using different tools, such as Basecamp or Google docs. And the computer programmers used git. I suspect this hurts an organization somewhat, chopping up its version control over so many different tools.

I'm curious if anyone thinks it is possible for git to ever catch up to Subversion in terms of ease of use?

I think for developers it is already as popular. I also like SVN though even with its flaws (apart from performance in larger projects, having a .svn folder everywhere is my biggest gripe).

I think git popularized versioning systems in the first place as many developers just didn't use them at all.

I hoped that versioning would become more user friendly. I remember offices with non-developers that used tools like Tortoise SVN for Windows, which is just insanely practical. Maybe there are already tools like that for git as well, but I haven't encountered them yet. Instead people use bad cloud sync software, which may solve some additional use cases. Problem is that most of these services are trash with bad performance.

But in the end, if SVN is used by non-developers it would still provide a massive benefit, it doesn't have to be git.

> apart from performance in larger projects, having a .svn folder everywhere is my biggest gripe

Working copy has only one .svn directory at its root in up-to-date Subversion client versions. The mentioned problem was fixed in SVN 1.7 (released in 2011).

> I think git popularized versioning systems in the first place as many developers just didn't use them at all.

It was not git. GitHub, its marketing and PR popularized git and version control in general. I think that before GitHub main focus was on versioning source code (recall SCM, source control management system). But the focus switched to universal version control (code + all non code assets).

Heh, shows how long I didn't use SVN anymore. But sure, I never really had a complained and used it quite extensively. But my surroundings often switched to git so I gave in to peer pressure I guess.

Funny thing is that GitHub almost removes the decentralized nature of git.

>I think git popularized versioning systems in the first place as many developers just didn't use them at all.

I think you didn't know many developers before ~2005[0], maybe? Or perhaps [almost] no professional devs before about then?

I was personally introduced to formal version control in 2004 (as the org I interned with went from CVS[1] to SVN[2]), but pretty much every developer I know was using it way before then

Heck! Forms of version control date back ~60 years at this point[3]

----------------

[0] https://en.wikipedia.org/wiki/Git

[1] https://en.wikipedia.org/wiki/Concurrent_Versions_System

[2] https://en.wikipedia.org/wiki/Apache_Subversion

[3] https://en.wikipedia.org/wiki/Version_control

The ease of use of Subversion is down to it being a centralized version control, which is pretty easy to understand. Switching to a distributed version control like Git takes quite a bit of effort (which I believe is worth it for more complex code bases being maintained by multiple people).

However, for a lot of business documents you want a single current version, with a history - Google Docs, Office 365 and similar give that to people in more user-friendly way than either Git or Subversion does, which is why they use it.

I bet that many are using git with GitHub. And GitHub is a centralized storage. It seems awkward that I’m using a distributed VCS as a centralized one, but have to dive into technical details about DVCSes.

It's still decentralised. GitHub is just one remote. I can copy/move an entire repo with history and all to a new remote with 2 commands.

This isn't possible with Subversion as the Subversion remote is the only single source/remote.

My take is that it is the other way around.

There are numerous web front ends for git such as github and bitbucket that are highly accessible to non-developers.

Certainly people complain that the index exists, like it's so hard that they have to type "git add" and then "git commit" and then "git push".

My counter to that is that git has sufficient complexity to be able to recover from operator errors more than any other version control system. I remember the very limited branching model in CVS where it was only really practical to do all the real development in the HEAD branch and just do maintenance for numbered versions. I remember how easy it was to completely destroy a Visual Source Safe repository.

In Git I've got no fear that some little mistake such as a typo in a commit message or checking changes into the wrong branch can't be fixed easily and that was not true for Subversion or any other system. This fact alone is a good reason why Git is a good choice for a project that has non-developer users because it means if they make mistakes due to a less-than-perfect conceptual understanding it is no big deal.

I think the issue is more that the tools that designers/marketers/salespeople use are moving to cloud solutions that manage versioning internally (figma/google docs/etc). It's harder to do features like multiplayer interfaces in local file-based workflows.

If SVN was so great for these non-developer use-cases, they could all still be using SVN. Just because the devs moved on to git, doesn't mean that SVN was made unavailable to these people. TortiseSVN still makes releases.

I remember Tortoise SVN. It integrated with Windows Explorer. You right clicked and got your history, committed, and did all the operations you needed. What a great tool...

There is/was Tortoise Git too. I moved from one to the other almost seamlessly back in the day.

I still use both Tortoise SVN and Tortoise Git, very fast, developer friendly and best of all, not Electron based.

I’ve been using git for the last ~14 years, at 5 startups. What’s Subversion?

Sure, I think most young devs would love to work with git. Subversion is rather used in legacy systems. Currently I don't see anything besides git.

For me Tortoise GIT + VS Git integration does the job.

I only use Git as a SVN replacement anyway, when anything goes wrong, I follow xkcd and clone from scratch, plain and simple.

I haven't seen anything but git in the last probably 10 years, except in the public sector

Are there really any SVN instances of import in the private sector out there any more?

Reply on news.ycombinator.com