GitHub Sunsetting Subversion Support

I wanted to announce this on April Fool's Day, but just couldn't make the timing work.

I remember having this problem with Gmail's "1GB for everyone!" April 1 announcement.

It's still running because Subversion has better CLI.

PS The joke is not that funny when it lasts for 13 years. Ha-ha, how funny (not).

A few different SVN -> Git migration tools failed to migrate a large legacy repo at a previous employer. I thought I was doomed to be stuck on subversion forever.

It was GitHub's migration that finally worked and got us migrated across.

Funny we were only svn because I had previously been part of an effort to migrate them to svn when I'd joined a few years prior because before that they were using an old TFS system where developers would block each other by checking out files which would lock them for the whole repo.

I knew that switching immediately to git would have been too much of a culture shock so I got them over to a CVS where people could at least work independently first. ( I also have a soft spot for svn anyway, I think for many small teams it works just as well as git with fewer opportunities to shoot oneself in the foot. )

https://svnhub.com/

heh heh heh, yeah nobody

Similarly, I added support to del.icio.us for color: urls for april fool's. It worked, correctly, everywhere.

Obviously it's unimportant compared to the rest of the post, but, in case you like to know, the feature is your brainchild. You would be its brainparent, I guess.

I have to point out that you've reversed the meaning of this word...

I imagine some of those are overcome by enforcing heuristics (e.g. the branches/tags/trunk hierarchy is mandatory and has business logic run based on it), but I'm really curious if there was ever a more detailed writeup on how it works?

Nothing lasts longer than a temporary fix.

So now we are stuck. Stick with unsupported Jira Server, pay $40k/yr for Jira Data Center (!!) or switch with all the business costs associated with that.

Seems likely to me that some significant percentage of GitHub SVN usage comes from decade-old scripts running on a build server somewhere. I suspect most of those users will choose to rewrite the script rather than moving to a new provider.

I think you're forgetting about Mercurial, which was also created by a Linux kernel developer around the same time. It brought all the same benefits of git, but had a simpler command line API and better cross platform support. Mercurial saw wide use, especially in large corporations like Facebook.

Indeed, a lot of people will say that it was the success of github itself that pushed git over the top. In a world where bitbucket won instead of github, we could all be using mercurial.

Although I've never used it, I'm not sure how much of an improvement either of these was over BitKeeper. The primary impetus to create git and mercurial was licensing changes in BitKeeper, not technical deficiencies.

It also let you put permissions on the repository itself, so if you didn't have the correct ACLs you couldn't see part of the code. It was really good for monorepos.

It has its quirks, and when I used it, could be a bit slower on the execution side, but generally thought it was really nice.

I also maintain that Mercurial & Fossil are superior to git, but git won the marketshare so its kinda moot now.

Literally reading it on GitHub's blog, where the whole endeavor has the name of a source control system in it.

Jokes aside, did they knew Git was going to win or did they just take on a massive risk that would otherwise gone wrong?

CVS though, uf da. We had some rough times in gamedev land until we moved over to SVN and then Perforce with proper proxies for a distributed team.

The truth is that git is pretty abysmal overall. There are commercial offerings that easily surpass it, if you are willing to pay.

Basically, the lead engineer that was in charge of the new project set up what he liked before the rest of the team was in place. So when I was hired on the team consisted of me, a senior engineer who hadn't used subversion in years, and a bunch of junior engineers who were completely unfamiliar with it. No amount of pleading would get him to migrate to git.

It was partially a control thing, I think. He liked having full control of the repo to himself. The system architecture was also... dated.

Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but haven't seen that being used anywhere really.

This is pretty much it, ease of use. No one really knows git (beyond 5 commands). Everyone knows how to google git commands or talks to the wizard in the company that can fix the mess someone created. While in theory git is more powerful, in the art of getting things done easily SVN wins, simple, stupid and it works.

There is also this: https://github.com/msofficesvn/msofficesvn

When you've got a ton of projects and their associated deployment pipelines all using SVN, the cost of migrating is non-zero. Someday I'll probably start (slowly) migrating, but the benefits just aren't great enough to make it a priority.

That said, SVN works, and I do think the learning issue is the primary obstacle for us moving to Git.

It should be said we're a small team though, 10 devs. I can imagine Git looking a lot more attractive to a larger team.

For my case: one|two developers + hundreds of read-only observers + a number of patch senders it is a perfect tool that far.

TortoiseSVN (Windows) and analogous tools (MacOS and Linux) are really unbeatable.

I am also using Git time to time but that is really far usability wise.

Five commands: commit, update, revert, merge and switch combined with FS explorer visualization are perfectly enough. Rarely: shelve(create patch) and unshelve(apply patch).

We switched a year or so ago to use git sparse checkout that was released in 2.25.

1. The trivial commit graph makes some concepts easier. You know from the commit number which is more recent. There are no complex merges.

2. The above makes for useful GUIs. There are no git GUIs that a user can not aim at their own foot, and needs the real client to clean up the mess.

3. The lack of complex operations makes access control easier. You still have to manage hooks, but it's easier or at least with less unintended consequences.

4. All clones are sparse. Together with a zero copy data storage makes for some cute concepts, such as branches and tags and directories actually being the same object. Sparse clones can be very useful.

5. The system tracks file system operations, such as moves and copies. It can actually be used for things, directly and without heuristics. (This is actually the one point where I can say I prefer the svn way. Git could have done something similar without breaking the conceptual model and it would have been useful.)

6. The metadata is, or at least used to be, more developed for non-unix file systems. I'm not sure if this is still the case.

7. Storing binary data is somewhat less bad. But still bad.

All that said, outside of specialized applications I'm not sure there's much reason to use svn for any new projects. And if you use it, keep in mind that git works perfectly well with svn archives. They just become a linear graph with funny commits and you can use that familiar git tools.

1) adoption. You're early in the Adoption Curve and you're trying to grease the wheels to make it easier for people to come for you

2) modernization work. You're brought in to consult for a company because someone has declared moral bankruptcy and decided that neutral third parties are more likely to dig them out of the problem. So as a consultant you show up week one and you say, "Dear God, they're still using X?" about five times. So now you're proposing to do migrations that all of your peers finished up seven years ago.

<I am a git user, who prefers it to anything>

E.g., people always like to point out that git is decentralised and svn is centralised. Bullshit. Centralisation and decentralisation are concepts, not absolute requirements. It's similar to the whole "you can't write object oriented code in c, you need c++" argument. Nope, you totally can. And also you can totally write completely non-object oriented c++. Case in point, most people who use git these days rely on a centralised use of git, namely through github. At my last job my use of svn was completely decentralised and worked like a charm.

I think the big thing for me is that, svn vs git shares a lot of similarities to the c vs c++ scenario: svn feels more low level, in that it is super flexible through its simplicity, but relies on good conventions as a result. git, on the other hand, tries to be opinionated about how things are to be done, and provides a specialised command for each task.

git feels very much like a "take-it-or-leave-it" solution to me. svn feels more like the early linux days: if you can afford to play around a bit to set up things just how you like them, then you can end up with a pretty sweet gig, that does exactly what you want it to.

https://stackoverflow.com/questions/3640764/can-i-recover-a-...

"Have you committed your changes to Svend yet?", "No, Svend is experiencing some downtime right now", that was some fun interactions that got us through computer science.

Git is a fun name too, but it is not nearly as funny to me.

TortoiseSVN was a great SVN client integrated into Windows File Explorer, and it looked great when you used the classic theme on Windows XP.

I've seen this happen a few times with a dev running `git push -f` with the intent to update their dev branch, except that it would force-push all branches in their clone that were associated with the remote, like master. It probably doesn't happen these days though, because the default was changed at some point to only push the current branch.

That's the only example of a well-known project I could find that's not directly related to subversion itself. I'm sure there are others, but all the other ones I could recall have since migrated (usually to git).

Earlier in my career, in the first week at one company I ended up corrupting the Subversion repo. I was a nervous wreck. My boss reassured and told me about he had also corrupted a Subversion repo previously as he restored the repo from backup.

I sometimes check out a single directory from a huge repository with enormous history. Since subversion only cares about the latest commit and the directory I'm checking out, it's instantaneous.

That's a joke right?

VSS is by far the shittiest VCS I've had the displeasure to use, though I will confess I never had to suffer through RCS and CVS.

It's certainly the only one which managed to destroy data. 'twas a good thing I'd already used other source control systems before VSS, because that experience would definitely have made me flee from source control systems for a while (much as Java did static type systems).

We switched to CVS and it was immediately better, followed by SVN a few years later. I still use git like a fancy subversion, just with multiple repositories :-)

There's some good links there that describe the trouble VSS caused.

There's also knock-on effects, e.g. an offering like this could attract the type of user that would add a lot of additional support burden for the value that the company _and_ the user gets out of the feature.

I'm confused by this. Microsoft released the VS Code source in 2015, long before they acquired GitHub in 2018 and sunset Atom in 2022.