Live data from Hacker News

GitHub Sunsetting Subversion Support

github.blog

81–90 of 238 posts

Re: GitHub Sunsetting Subversion Support

#81
post #69

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 haven't used svn Yeahhhh. Svn is centralized. You must be connected to the server to do any source control work. There is no local repository, there are no local commits. Every commit is global on the server. When you make a commit, it is pushed to the server and your coworkers can fetch it. You don't make commits locally and fiddle around and then push. Also Svn doesn't have branches per se. You just use subdire…

> Also Svn doesn't have branches per se. You just use subdirectories. It does have facilities for merging directories and managing these "branches", but it feels real weird to be switching branches with 'cd'.

Also, this means that it's possible to do some horrifying things with branches and tags, like making a merge commit which is isolated to a single directory, or checking out a tag and making a commit to it.

Hopefully no one is actually depending on these workflows being possible, because they make project history extremely hard to follow.

Re: GitHub Sunsetting Subversion Support

#82
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.

I am using it for Sciter development.

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).

Re: GitHub Sunsetting Subversion Support

#83
> But hey, if the Subversion system just works and doesn’t bother anyone, there’s no reason to make any changes, right? The reality is that there’s an ongoing maintenance cost to any software, and that goes extra for public-facing services on the internet.

This is a poor excuse. I understand that MSFT/Github feels compelled to provide a convincing reason to users, but this is not it. 99.9% of problems are caused by developers making changes or pushing new code. I've been writing software for close to two decades now--if you don't touch it, it's not going to break on its own.

Re: GitHub Sunsetting Subversion Support

#85
post #24

Earlier quoted context omitted.

As the PM who ended up finally killing it, I (on behalf of the team) thank you for your "joke" that wasn't really a joke. It did help some customers who had legacy SVN workloads land on GitHub. I wanted to announce this on April Fool's Day, but just couldn't make the timing work.

> I wanted to announce this on April Fool's Day, but just couldn't make the timing work. Thank you for not doing that. Releasing a wacky feature on April 1 is funny. Discontinuing a service that people might rely on is distinctly un-funny.

I disagree. It would probably prompt a few support calls and emails, but otherwise I think it would be great.

Re: GitHub Sunsetting Subversion Support

#86

Earlier quoted context omitted.

As the PM who ended up finally killing it, I (on behalf of the team) thank you for your "joke" that wasn't really a joke. It did help some customers who had legacy SVN workloads land on GitHub. I wanted to announce this on April Fool's Day, but just couldn't make the timing work.

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

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

Re: GitHub Sunsetting Subversion Support

#87

Earlier quoted context omitted.

I think April 1st should definitely be "Crazy-but-real announcement day". It'll take some attention off the unfunnier-every-year "jokes" which have turned a pleasant and fun yearly occasion into the internet being unusable for ~36 hours.

You mean the internet being actually lighthearted and fun (like it used to be) for 36 hours?

You sound like the kind of person who thinks saying "it's just a prank bro" makes a variety of awful behaviour ok.

AF is a day with a mix of corpos trying So Hard To Be Cool (remember this shit? https://www.theverge.com/2016/4/1/11344044/google-gmail-mic-...) and plainer-than-usual disinformation campaigns.

The only redeeming thing about that day is I get to have an excuse to not be reachable for a day and can be disconnected for a while. Hopefully my loved ones don't end up in the hospital on bad timing.

Re: GitHub Sunsetting Subversion Support

#88

> But hey, if the Subversion system just works and doesn’t bother anyone, there’s no reason to make any changes, right? The reality is that there’s an ongoing maintenance cost to any software, and that goes extra for public-facing services on the internet. This is a poor excuse. I understand that MSFT/Github feels compelled to provide a convincing reason to users, but this is not it. 99.9% of problems are caused by d…

The "ongoing maintenance cost of software" can also be the additional complexity in the mental model of developers that have to deal with nearby parts of the codebase. Even if no maintenance is needed for a specific feature, it doesn't always make sense to keep around.

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.

Re: GitHub Sunsetting Subversion Support

#89
post #53
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.

"easier to use" a great reason to prefer it. I want to write software, not manage a source control system.

"I want to write software, not manage a source control system."

Exactly!

Re: GitHub Sunsetting Subversion Support

#90
post #21

The one thing I really miss about svn is the central,authoritative, auto-incrementing revision numbers. Git hashes are less friendly to use - in the svn days it was easy to tell at a glance if you had an earlier or later version. Yes, I know the many ways that git is better in practice, and would miss some of the workflows git's nature allows if they were gone. But we really did lose something too, especially when ru…

It can be done, but probably shouldn't: https://github.com/zegl/extremely-linear/commits/main

> With the shit ("short git") wrapper, you can use commands like shit show 14, and shit log 100..150

I found this amusing.

Post reply on HN