GitHub Sunsetting Subversion Support • Hacker News Board

Re: GitHub Sunsetting Subversion Support

#101

Post by vtbassmatt » Fri, Jan 20, 2023, 9:31 PM UTC

eterm wrote: post #72

schacon wrote: post #12

As one of the GitHub cofounders and the brainchild of this particular feature, I want to let everyone know that this is maybe the funniest thing I've ever done. We released this feature and published the announcing blog post, on April Fool's Day, 2010. I remember demoing it to the other GitHub guys and saying how funny it would be if we made this an April Fool's day post as though it was a big stupid joke but then it…

Thank you. 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 T…

FWIW we aren't planning to turn off Subversion import [1]. Only the two-way bridge where you could keep using `svn` against the Git repo.

[1] https://docs.github.com/en/get-started/importing-your-projec...

Re: GitHub Sunsetting Subversion Support

#102

Post by msoucy » Fri, Jan 20, 2023, 9:34 PM UTC

rr808 wrote: post #91

TimTheTinker wrote: post #50

Earlier quoted context omitted.

Jeff Atwood had a lot of negative things to say about Visual SourceSafe back in 2006: https://blog.codinghorror.com/source-control-anything-but-so... There's some good links there that describe the trouble VSS caused.

Lol the comments. I went through Perforce and ClearCase too.

I try to forget ClearCase.

It haunts my nightmares.

When we were migrating to git, some of the more senior engineers came up with a workflow that was described as "the best implementation of ClearCase in git that I've ever seen". It was meant as a compliment.

Re: GitHub Sunsetting Subversion Support

#103

Post by js2 » Fri, Jan 20, 2023, 9:37 PM UTC

woodruffw wrote: post #67

Only partially related, but since they mention it at the bottom of the post: I really like GH's "brownout" approach to discontinuing services. They've done it a couple of times before (like this one[1]), and it's always struck me as a very sensible way to handle deprecations on such a massive service. [1]: https://github.blog/changelog/2021-08-10-brownout-notice-api...

These are also known as scream tests. We use them internally at $dayjob as part of EOL'ing APIs. Are they not common?

Re: GitHub Sunsetting Subversion Support

#104

Post by IgorPartola » Fri, Jan 20, 2023, 9:39 PM UTC

colonelpopcorn wrote: post #86

IgorPartola wrote: post #65

Earlier quoted context omitted.

Instead add FTP version control support with the ability to create backup files.

source.php.old.ReallyOld.bak.thistimeitsold.old

Exactly. When it is a small change, just comment it out. But when it’s a large change, create a .old.backup.2013-12-07.dontdelete.

Re: GitHub Sunsetting Subversion Support

#105

Post by avgcorrection » Fri, Jan 20, 2023, 9:40 PM UTC

gmueckl wrote: post #98

avgcorrection wrote: post #68

Earlier quoted context omitted.

Maybe you can count the first parent commits on mainline, and then reverse that list.

Git doesn't have a good concept of a mainline branch when going back past a merge. It simply records more than one parent for that commit and not which branches they were on before they got merged. Mercurial does somewhat better in that department by storing the branch name in the commit, so you can pick the parent on the same branch reliably.

I don’t understand what you’re saying. If you have a main branch which is always merged into then `--first-parent` will only list merge commits and regular commits on that branch. I have never seen it fail on our main branch.

In `git merge feature`, `feature` will become the second parent while the commit that you are on will become the first. The linear mainline history falls out of that.

Re: GitHub Sunsetting Subversion Support

#106

Post by jwcooper » Fri, Jan 20, 2023, 9:40 PM UTC

kypro wrote: post #25

I'd love to hear from someone who's still using SVN professionally and can explain why they prefers it to Git. I used SVN very early in my career. I think the only good thing I can say about it is that it's easier to learn. It's quite easy to teach a junior dev how to use SVN. Git takes much longer to master.

We used SVN in an application to grab a single folder and its contents from a repo on GitHub. It was the quickest and easiest approach at the time (that I knew of) and worked well.

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

Re: GitHub Sunsetting Subversion Support

#107

Post by arcticgeek » Fri, Jan 20, 2023, 9:42 PM UTC

kadoban wrote: post #73

somerando7 wrote: post #41

Earlier quoted context omitted.

What's better about git? I haven't used svn, but have used perforce/mercurial professionally/git professionally, and use git personally, but I find all of them to provide the same "feature set" when doing basic development: have your own branch, and merge it in to the main branch when done/reviewed. Merging seems the same on all 3 version control systems I've used... I've heard that git branching is better(?), but ha…

> I've heard that git branching is better(?), but haven't seen that being used anywhere really. How are you merging without branches? Git is mostly faster and more flexible than svn, and the merging works far better. Unless svn's merging has improved in the past decade or so, which is entirely possible. When I switched to git from svn, the main differences were: merging was usable, making new branches and switching b…

Yes, that’s actually the thing about branching in SVN. Everyone remembers how awful it was 10+ years ago under SVN 1.4 and earlier but has improved immensely since then. Combined with modern client tooling, i.e. TortoiseSVN, problems with merging are almost non-existent for a long time.

I certainly wouldn’t call SVN modern but it’s very well maintained and has never lost code on me. Many git-like features also exist now such as being able to stash some changes in order to pivot to something else for a bit. Except for the central server being a problem for some use-cases, SVN just works.

Re: GitHub Sunsetting Subversion Support

#108

Post by neallindsay » Fri, Jan 20, 2023, 9:44 PM UTC

I remember when they added Subversion support; I thought it was hilarious. And it worked!

This quote from the linked blog post made me raise my eyebrows though:

> In 2010…it was not yet clear that distributed version control would eventually take over, and even less clear that Git would be the dominant system.

I think it was actually extremely clear that Git would win. It had a guaranteed audience by virtue of hosting the Linux kernel. And forget even about its distributed nature; Git was already better at the centralized model than "centralized-only" version control systems ever were.

When Subversion came out I was overjoyed; finally someone had fixed most of the broken things about CVS. I jumped on it with gusto. But when Git came out it was so much better than SVN that I was blown away. And it wasn't long before there were great tools to translate between SVN and Git. By the time Github released its SVN bridge feature I think the place I was working at had already used those freely-available tools to move our old SVN repos to Git with full history. It was so easy to do! The only hard part was organizing all the developers to stop using the SVN server and switch to pushing to the Git server at the same time.

Sometimes a new technology comes out and it's immediately obvious that it's the future. The ones that come to mind for me are Git, the iPhone, and node.js.

Re: GitHub Sunsetting Subversion Support

#109

Post by arcticgeek » Fri, Jan 20, 2023, 9:46 PM UTC

masklinn wrote: post #29

rr808 wrote: post #11

How about Visual SourceSafe? I actually loved that for a small team.

> I actually loved that for a small team. 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…

We used to call it Visual Source Shredder because of how easy it was to corrupt the database.

Re: GitHub Sunsetting Subversion Support

#110

Post by jeppester » Fri, Jan 20, 2023, 9:47 PM UTC

_da_ wrote: post #77

singularity2001 wrote: post #71

Is there an alternative way to download select folders without svn?

> Why do people still use Subversion on GitHub, anyhow? Besides simple inertia, there were workflows which Git didn’t support until recently. The main thing we heard when speaking with customers and communities was checking out a subset of the repository–a single directory, or only the latest commit. I have good news: with sparse checkout, sparse index, and partial clone, Git can now do a pretty decent job at these w…

With these features I can have a local clone with just a subfolder, and without downloading all the history. But it still comes with git - which I'll then have to remove for my use case.

I really think that grabbing some files from a certain commit should be a completely trivial oneliner.