14 ms·

GitHub Sunsetting Subversion Support

319 points by mikece 4y ago

thrownaway561 4y ago
About time... I don't know a single person that still uses it. I can't tell you how many times I got burned doing merges in Subversion where the entire repo became corrupt. Git was a life saver when it came out and I switched immediately over to it.
- RcouF1uZ4gsC 4y ago
  > I can't tell you how many times I got burned doing merges in Subversion where the entire repo became corrupt. 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.
  - david422 4y ago
    Uggh. If there's one thing I would want to be super stable it would be my version control!
- andrewshadura 4y ago
  I do. 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.
doublepg23 4y ago
Not sure I’m familiar with any projects using Subversion. I think the most odd-ball version control I’ve seen in prod is SQLite using Fossil (which does seem to have benefits over git) and OpenBSD sticking with CVS.
- jldugger 4y ago
  SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.
  - avereveard 4y ago
    SVN had a great feature set, and a great way to handle merges, and sane defaults. too bad they hit some limits as repos become larger and larger, tried to implement a new storage engine, and basically they never managed to iron out all bugs out of it in time, while the older storage engine entered feature freeze and was basically abandoned. I've been checking them for years, and there were file corruption issue for so long, I lost interest in tracking the status anymore, as by that point I wrapped my head around the git model.
    - masklinn 4y ago
      > and a great way to handle merges Nope. That took a very long while to be added. When the current crop of DVCS started appearing, one of their significant draw was actually that by necessity merges worked well. At the time, SVN made it extremely easy to fork branches, and almost impossible to merge them. Per the official doc (https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmer...) merge tracking was introduced in subversion 1.5, released in May 2008. That's 3 years after the initial release of Git, Mercurial, and Bazaar. Before then you had to keep note of what you'd merged by hand so you didn't double merge it, and that was distinctly not fun.
    - msbarnett 4y ago
      > SVN had a great feature set, and a great way to handle merges, and sane defaults. Are you kidding? Subversion had a notoriously awful way of handling merges, which was a huge driver of people onto Git as soon as it appeared. You truly had to have been there to believe it, but in all but the simplest of merge scenarios, declaring branch bankruptcy and manually moving things back into the target branch by hand was your only real option. Early to mid 2000s, the most common team branching strategy I saw with subversion was "there's only one branch and everybody does all the development in it because god help you if you try to put it back together after branching for something". It wasn't until well after the momentum was clearly in Git's favour and a huge chunk of the user base was gone that Subversion finally fixed it to not be complete dogshit.
carrja99 4y ago
No!
deleted 4y ago
[deleted]
voidfunc 4y ago
Didn't even know GitHub had svn support... it's been about a decade since I've even had to interact with a subversion repo professionally also.
CJefferson 4y ago
There is only one thing about subversion I miss when using git -- the deletion of branches (which were, admittedly, just directories in a folder called branches) was version controlled, so you could recover deleted branches.
- nighthawk454 4y ago
  Just in case - you can in git as well. Branches are just pointers to a commit SHA, so can always create another pointer to the same commit and your branch is back. https://stackoverflow.com/questions/3640764/can-i-recover-a-branch-after-its-deletion-in-git https://stackoverflow.com/questions/3640764/can-i-recover-a-...
  - stouset 4y ago
    I suspect GP knows this, but there's no way to go back and see what the branch ref was at a prior point in time. I believe they wish that refs themselves were versioned. And yes, I know they're kept in the reflog. But that is short-lived and (I believe) local rather than eternal and global like everything else in git.
    - CJefferson 4y ago
      Yes, as you say, I'd have to write the commit names down, and eventually they would get garbage collected. You could tag, but then you are just polluting your tag namespace with old branches.
      - sicp-enjoyer 4y ago
        You can also search logs to recover a commit, besides the other ways mentioned. > ok but then I lose it's nice handle. Then don't delete the handle? Maybe rename it with a `deleted/` prefix? It's hard to imagine what the expected behaviour is when branch names are just local convenience labels.
    - ecnahc515 4y ago
      The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server, so not much use in eg, GitHub. That being said, GitHub also exposes some of these details, for example: in PRs when you force push on your branch. So in the general sense, there's no reason we can't have exactly what's being discussed, but it just doesn't exist yet.
rr808 4y ago
How about Visual SourceSafe? I actually loved that for a small team.
- tialaramex 4y ago
  Are you serious? I'm not even sure if Visual SourceSafe is better than "Once a week I copy all the files into a ZIP and date it" as a strategy for version management.
  - msbarnett 4y ago
    for one thing, zips are far less likely to destroy data than sourcesafe, which was famous for doing just that
- masklinn 4y ago
  > 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 a while (much as Java did static type systems).
  - arcticgeek 4y ago
    We used to call it Visual Source Shredder because of how easy it was to corrupt the database.
- ianmcgowan 4y ago
  Worst. VCS. Ever! Can't believe anyone ever loved VSS - it was constantly corrupting the repository, people would lock programs and go on vacation, just a constant struggle. 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 :-)
- TimTheTinker 4y ago
schacon 4y ago
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 actually completely worked on every repository we had and we all thought it would be great. Until nobody believed us. Which in hindsight we should have seen coming, since that was the joke, but nobody actually tried it. Then people tried it and it worked and they thought it was a trick or something. It was really helpful for people migrating from legacy SVN based systems to us (CI and stuff) but I'm surprised to some degree that it's still running 13 years later when nobody is really facing that issue anymore. And I'm still undecided if the joke was worth the massive confusion it caused. But if I'm pressed, I would say that I would 100% release it on April Fool's Day again.
- vtbassmatt 4y ago
  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.
  - schacon 4y ago
    I tip my hat to your team and I owe you all beers, my friends. You are doing the lord's work.
  - klyrs 4y ago
    > 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.
    - adamdusty 4y ago
      I disagree. It would probably prompt a few support calls and emails, but otherwise I think it would be great.
Shank 4y ago
This reminds me of when Slack shutdown its IRC bridge [0], and in a pretty negative way. I get that usage is down, but that tends to happen. Supporting niche users is how you win customer goodwill. The active users of SVN on GitHub clearly aren't going to switch to git, and I can respect the maintenance costs, but they're probably just going to switch to a different provider. For them, their workflow is now in-danger and they have to solve that problem in-addition to whatever they're working on. I always thought it was a lovely little feature GitHub supported, and I'm sad to see it go for this reason. [0]: https://it.slashdot.org/story/18/03/08/2049255/slack-is-shutting-down-its-irc-gateway https://it.slashdot.org/story/18/03/08/2049255/slack-is-shut...
- arp242 4y ago
  There's some differences as well: GitHub gives a year lead-time, Slack gave two months. IRC and XMPP are a fundamentally different workflows from that horrible web UI, subversion (for basic commands) is not all that different than git (alias svn=git can almost work).
- kejaed 4y ago
  I relate here with Atlassian discontinuing their Jira Server product. I suppose they did the analysis and it wasn’t worth their dev time but there are some customers who CANT move to Jira Cloud for compliance reasons. 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.
  - adra 4y ago
    They want those subscription revenues and that's as simple as that. In 2-5 years server will be back as never before but you'll be paying a subscription rate.
    - kejaed 4y ago
      Sounds about right! And look, so much less expensive than Data Center per year!
benatkin 4y ago
GitHub hasn't heard of Docker? It seems they could use it to run Subversion without any effect on their git hosting. Just kidding, but remember back in the DotCloud days when they pointed out you could run Perl? That was pretty cool. https://news.ycombinator.com/item?id=2518526 https://news.ycombinator.com/item?id=2518526 > In 2010, when GitHub introduced Subversion support, the version control landscape was very different. That was waaaaay before Microsoft acquired it. > 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. As the use of GitHub has evolved and the number of Subversion requests has declined dramatically, we plan to focus our efforts entirely on Git. Reminds me of how Microsoft dumped Atom (and then fauxpen-sourced VSCode before dumping the last remnants of Atom).
- czx4f4bd 4y ago
  > Reminds me of how Microsoft dumped Atom (and then fauxpen-sourced VSCode before dumping the last remnants of Atom). 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.
  - benatkin 4y ago
    They moved Atom into de-facto maintenance mode much earlier than that, when VSCode was much less fauxpen-source than it is now.
    - czx4f4bd 4y ago
      Just repeating "fauxpen source" doesn't mean anything to me. What actual change are you referring to?
      - benatkin 4y ago
        Big overview: https://ghuntley.com/fracture/ https://ghuntley.com/fracture/ A couple points in time: Pylance, installed by default, won't open source. Microsoft keeps calling VSCode open source. https://github.com/microsoft/pylance-release/issues/4 https://github.com/microsoft/pylance-release/issues/4 Same for .NET https://twitter.com/migueldeicaza/status/1537175065380495367 https://twitter.com/migueldeicaza/status/1537175065380495367
reindeerer 4y ago
github had subversion support ??? :)
thaeli 4y ago
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 running git in "quasi-centralized" mode such as on GitHub.
- scottlamb 4y ago
  It's not as simple, but you might be able to get what you want with `git describe`. E.g., a working copy of mine now says `v0.7.5-43-g9060dbf`: 43 commits after tag `v0.7.5`, hash `9060dbf...`.
- david_allison 4y ago
  It can be done, but probably shouldn't: https://github.com/zegl/extremely-linear/commits/main https://github.com/zegl/extremely-linear/commits/main
  - rascul 4y ago
    > With the shit ("short git") wrapper, you can use commands like shit show 14, and shit log 100..150 I found this amusing.
- avgcorrection 4y ago
  Maybe you can count the first parent commits on mainline, and then reverse that list.
  - gmueckl 4y ago
    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.
kypro 4y ago
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.
- gowld 4y ago
  "easier to use" a great reason to prefer it. I want to write software, not manage a source control system.
  - c-smile 4y ago
    "I want to write software, not manage a source control system." Exactly!
- gmueckl 4y ago
  SVN is still simply unsurpassed by any other open source version control I know when it comes to the handling of large files and fine grained access control. The truth is that git is pretty abysmal overall. There are commercial offerings that easily surpass it, if you are willing to pay.
- jcadam 4y ago
  Not using it now, but the last project I was on that did was at a defense contractor about 5 years ago. 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.
- somerando7 4y ago
  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 haven't seen that being used anywhere really.
adamsb6 4y ago
This reminds me of the time on Something Awful that radium banned the one user that was using WebTV. > About 91% of visitors are on Windows. Mac users make up 5% and Linux is 2%. The other 2% are permabanned IRC trolls browsing the forums with a text-based browser written in Ruby on OpenBSD. Oh yeah, we have one guy using WebTV but I banned him because WTF.
- mjhay 4y ago
  Hadn't heard that one before. Radium's incompetence was really something.
- Jolter 4y ago
  He may very well have just made that up.
- pram 4y ago
  Lowtax banned Phoenix/Firebird at one point, early on. He didn’t like people complaining that stuff didn’t render correctly. He only allowed Internet Explorer for some time. It wasn’t funny.
woodruffw 4y ago
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-authentication-via-query-parameters-for-48-hours/ https://github.blog/changelog/2021-08-10-brownout-notice-api...
- js2 4y ago
  These are also known as scream tests. We use them internally at $dayjob as part of EOL'ing APIs. Are they not common?
  - woodruffw 4y ago
    I have no clue! I just appreciated them as a lowly user.
  - CodexArcana 4y ago
    Lol brown outs is such a nicer name, but I've always known them as a scream test.
    - adamckay 4y ago
      They're ever so slightly different. Scream test is to discontinue service entirely and see who screams, akin to pulling the plug on a server in a rack when you've got no idea what's running on it, to then plug in back in when you find out it's the finance team running payroll software. Brown outs are typically short-lived purposeful errors or aborts to either shed load to prevent a failure due to capacity exhaustion or cause issues that are investigated by a human to find the service has been sunsetted which raise awareness that something needs to be fixed before it's totally broken.
- travisjungroth 4y ago
  Make sure to get the rate right. Like 1/1,000 or 1/100,000. Poetry did a brownout of its install script at 5% failure. With a matrix of builds user's CI had closer to a 100% chance of failing.
singularity2001 4y ago
Is there an alternative way to download select folders without svn?
- _da_ 4y ago
  > 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 workflows.
  - jeppester 4y ago
    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.
    - WorldMaker 4y ago
      If you are already using GitHub you can write your own short scripts with GitHub's file raw URLs (which include a specific commit hash) and curl/httpie. Obviously, that's not easily portable to other hosts (though most of the big ones have similar URL patterns that you can discover), but depending on your use case may be a handy option. > But it still comes with git - which I'll then have to remove for my use case. I don't know what your use case is, or why you don't have a local history anyway of the repo so that you need to spot-download sub-trees, but if this is a somewhat common workflow this seems to indicate you may possibly be looking for something like git-archive [1]. That's a tool included in the "corners" of the git "suite" to take a `treeish` and build a tar or zip directly from it (with no git metadata inside). You can use a commit or a tag name for a `treeish`, but if you wanted it to be a specific folder inside a commit you can pull the commit, examine the tree it points to until you find the tree ID inside that representing just the subfolder you are looking for. You can pass that tree ID to git-archive. (And other things that take a `treeish`.) It's not quite a "completely trivial oneliner" to write a script to do that, but it may not be that much more complicated of a script to write. [1] https://git-scm.com/docs/git-archive https://git-scm.com/docs/git-archive
lopkeny12ko 4y ago
> 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.
- sastraxi 4y ago
  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.
renewiltord 4y ago
I had no idea. This is fucking great. Hahaha. Best thing I've read all day.
neallindsay 4y ago
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.
- yoden 4y ago
  > 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. 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.
  - neallindsay 4y ago
issafram 4y ago
This part made me laugh "Late in 2023, we’ll run a few hours-long and then day-long brownouts to help flush out any remaining use of the feature." I'd prefer just spam emails saying the system is shutting down
- Aachen 4y ago
  And after the email spam, it just shuts off? Wouldn't a temporary outage be a better way to attend those not reading the old email box used to sign up for Github that they need to upgrade their software?
bradfitz 4y ago
They had Subversion support?
SeanLuke 4y ago
<sigh> I still use the svn bridge as my primary way to acces GitHub repositories: I get around much faster in svn than in git and have little need for a VCS except in special circumstances. Kinda dreading this.
jesuspiece 4y ago
When are we going to admit to ourselves that everything else is worse than git?
xerxesaa 4y ago
In the many years I've used github, I honestly never even realized they supported svn.
therufa 4y ago
what does sunsetting mean?

319 points by mikece 4y ago

About time... I don't know a single person that still uses it. I can't tell you how many times I got burned doing merges in Subversion where the entire repo became corrupt. Git was a life saver when it came out and I switched immediately over to it.

RcouF1uZ4gsC 4y ago
> I can't tell you how many times I got burned doing merges in Subversion where the entire repo became corrupt. 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.
- david422 4y ago
  Uggh. If there's one thing I would want to be super stable it would be my version control!
andrewshadura 4y ago
I do. 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.

doublepg23 4y ago

Not sure I’m familiar with any projects using Subversion. I think the most odd-ball version control I’ve seen in prod is SQLite using Fossil (which does seem to have benefits over git) and OpenBSD sticking with CVS.

jldugger 4y ago
SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.
- avereveard 4y ago
  SVN had a great feature set, and a great way to handle merges, and sane defaults. too bad they hit some limits as repos become larger and larger, tried to implement a new storage engine, and basically they never managed to iron out all bugs out of it in time, while the older storage engine entered feature freeze and was basically abandoned. I've been checking them for years, and there were file corruption issue for so long, I lost interest in tracking the status anymore, as by that point I wrapped my head around the git model.
  - masklinn 4y ago
    > and a great way to handle merges Nope. That took a very long while to be added. When the current crop of DVCS started appearing, one of their significant draw was actually that by necessity merges worked well. At the time, SVN made it extremely easy to fork branches, and almost impossible to merge them. Per the official doc (https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html https://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmer...) merge tracking was introduced in subversion 1.5, released in May 2008. That's 3 years after the initial release of Git, Mercurial, and Bazaar. Before then you had to keep note of what you'd merged by hand so you didn't double merge it, and that was distinctly not fun.
  - msbarnett 4y ago
    > SVN had a great feature set, and a great way to handle merges, and sane defaults. Are you kidding? Subversion had a notoriously awful way of handling merges, which was a huge driver of people onto Git as soon as it appeared. You truly had to have been there to believe it, but in all but the simplest of merge scenarios, declaring branch bankruptcy and manually moving things back into the target branch by hand was your only real option. Early to mid 2000s, the most common team branching strategy I saw with subversion was "there's only one branch and everybody does all the development in it because god help you if you try to put it back together after branching for something". It wasn't until well after the momentum was clearly in Git's favour and a huge chunk of the user base was gone that Subversion finally fixed it to not be complete dogshit.

carrja99 4y ago

No!

deleted 4y ago

[deleted]

voidfunc 4y ago

Didn't even know GitHub had svn support... it's been about a decade since I've even had to interact with a subversion repo professionally also.

CJefferson 4y ago

There is only one thing about subversion I miss when using git -- the deletion of branches (which were, admittedly, just directories in a folder called branches) was version controlled, so you could recover deleted branches.

nighthawk454 4y ago
Just in case - you can in git as well. Branches are just pointers to a commit SHA, so can always create another pointer to the same commit and your branch is back. https://stackoverflow.com/questions/3640764/can-i-recover-a-branch-after-its-deletion-in-git https://stackoverflow.com/questions/3640764/can-i-recover-a-...
- stouset 4y ago
  I suspect GP knows this, but there's no way to go back and see what the branch ref was at a prior point in time. I believe they wish that refs themselves were versioned. And yes, I know they're kept in the reflog. But that is short-lived and (I believe) local rather than eternal and global like everything else in git.
  - CJefferson 4y ago
    Yes, as you say, I'd have to write the commit names down, and eventually they would get garbage collected. You could tag, but then you are just polluting your tag namespace with old branches.
    - sicp-enjoyer 4y ago
      You can also search logs to recover a commit, besides the other ways mentioned. > ok but then I lose it's nice handle. Then don't delete the handle? Maybe rename it with a `deleted/` prefix? It's hard to imagine what the expected behaviour is when branch names are just local convenience labels.
  - ecnahc515 4y ago
    The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server, so not much use in eg, GitHub. That being said, GitHub also exposes some of these details, for example: in PRs when you force push on your branch. So in the general sense, there's no reason we can't have exactly what's being discussed, but it just doesn't exist yet.

rr808 4y ago

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

tialaramex 4y ago
Are you serious? I'm not even sure if Visual SourceSafe is better than "Once a week I copy all the files into a ZIP and date it" as a strategy for version management.
- msbarnett 4y ago
  for one thing, zips are far less likely to destroy data than sourcesafe, which was famous for doing just that
masklinn 4y ago
> 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 a while (much as Java did static type systems).
- arcticgeek 4y ago
  We used to call it Visual Source Shredder because of how easy it was to corrupt the database.
ianmcgowan 4y ago
Worst. VCS. Ever! Can't believe anyone ever loved VSS - it was constantly corrupting the repository, people would lock programs and go on vacation, just a constant struggle. 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 :-)
TimTheTinker 4y ago

schacon 4y ago

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 actually completely worked on every repository we had and we all thought it would be great. Until nobody believed us. Which in hindsight we should have seen coming, since that was the joke, but nobody actually tried it. Then people tried it and it worked and they thought it was a trick or something. It was really helpful for people migrating from legacy SVN based systems to us (CI and stuff) but I'm surprised to some degree that it's still running 13 years later when nobody is really facing that issue anymore. And I'm still undecided if the joke was worth the massive confusion it caused. But if I'm pressed, I would say that I would 100% release it on April Fool's Day again.

vtbassmatt 4y ago
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.
- schacon 4y ago
  I tip my hat to your team and I owe you all beers, my friends. You are doing the lord's work.
- klyrs 4y ago
  > 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.
  - adamdusty 4y ago
    I disagree. It would probably prompt a few support calls and emails, but otherwise I think it would be great.

Shank 4y ago

This reminds me of when Slack shutdown its IRC bridge [0], and in a pretty negative way. I get that usage is down, but that tends to happen. Supporting niche users is how you win customer goodwill. The active users of SVN on GitHub clearly aren't going to switch to git, and I can respect the maintenance costs, but they're probably just going to switch to a different provider. For them, their workflow is now in-danger and they have to solve that problem in-addition to whatever they're working on. I always thought it was a lovely little feature GitHub supported, and I'm sad to see it go for this reason. [0]: https://it.slashdot.org/story/18/03/08/2049255/slack-is-shutting-down-its-irc-gateway https://it.slashdot.org/story/18/03/08/2049255/slack-is-shut...

arp242 4y ago
There's some differences as well: GitHub gives a year lead-time, Slack gave two months. IRC and XMPP are a fundamentally different workflows from that horrible web UI, subversion (for basic commands) is not all that different than git (alias svn=git can almost work).
kejaed 4y ago
I relate here with Atlassian discontinuing their Jira Server product. I suppose they did the analysis and it wasn’t worth their dev time but there are some customers who CANT move to Jira Cloud for compliance reasons. 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.
- adra 4y ago
  They want those subscription revenues and that's as simple as that. In 2-5 years server will be back as never before but you'll be paying a subscription rate.
  - kejaed 4y ago
    Sounds about right! And look, so much less expensive than Data Center per year!

benatkin 4y ago

GitHub hasn't heard of Docker? It seems they could use it to run Subversion without any effect on their git hosting. Just kidding, but remember back in the DotCloud days when they pointed out you could run Perl? That was pretty cool. https://news.ycombinator.com/item?id=2518526 https://news.ycombinator.com/item?id=2518526 > In 2010, when GitHub introduced Subversion support, the version control landscape was very different. That was waaaaay before Microsoft acquired it. > 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. As the use of GitHub has evolved and the number of Subversion requests has declined dramatically, we plan to focus our efforts entirely on Git. Reminds me of how Microsoft dumped Atom (and then fauxpen-sourced VSCode before dumping the last remnants of Atom).

czx4f4bd 4y ago
> Reminds me of how Microsoft dumped Atom (and then fauxpen-sourced VSCode before dumping the last remnants of Atom). 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.
- benatkin 4y ago
  They moved Atom into de-facto maintenance mode much earlier than that, when VSCode was much less fauxpen-source than it is now.
  - czx4f4bd 4y ago
    Just repeating "fauxpen source" doesn't mean anything to me. What actual change are you referring to?
    - benatkin 4y ago
      Big overview: https://ghuntley.com/fracture/ https://ghuntley.com/fracture/ A couple points in time: Pylance, installed by default, won't open source. Microsoft keeps calling VSCode open source. https://github.com/microsoft/pylance-release/issues/4 https://github.com/microsoft/pylance-release/issues/4 Same for .NET https://twitter.com/migueldeicaza/status/1537175065380495367 https://twitter.com/migueldeicaza/status/1537175065380495367

reindeerer 4y ago

github had subversion support ??? :)

thaeli 4y ago

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 running git in "quasi-centralized" mode such as on GitHub.

scottlamb 4y ago
It's not as simple, but you might be able to get what you want with `git describe`. E.g., a working copy of mine now says `v0.7.5-43-g9060dbf`: 43 commits after tag `v0.7.5`, hash `9060dbf...`.
david_allison 4y ago
It can be done, but probably shouldn't: https://github.com/zegl/extremely-linear/commits/main https://github.com/zegl/extremely-linear/commits/main
- rascul 4y ago
  > With the shit ("short git") wrapper, you can use commands like shit show 14, and shit log 100..150 I found this amusing.
avgcorrection 4y ago
Maybe you can count the first parent commits on mainline, and then reverse that list.
- gmueckl 4y ago
  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.

kypro 4y ago

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.

gowld 4y ago
"easier to use" a great reason to prefer it. I want to write software, not manage a source control system.
- c-smile 4y ago
  "I want to write software, not manage a source control system." Exactly!
gmueckl 4y ago
SVN is still simply unsurpassed by any other open source version control I know when it comes to the handling of large files and fine grained access control. The truth is that git is pretty abysmal overall. There are commercial offerings that easily surpass it, if you are willing to pay.
jcadam 4y ago
Not using it now, but the last project I was on that did was at a defense contractor about 5 years ago. 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.
somerando7 4y ago
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 haven't seen that being used anywhere really.

adamsb6 4y ago

This reminds me of the time on Something Awful that radium banned the one user that was using WebTV. > About 91% of visitors are on Windows. Mac users make up 5% and Linux is 2%. The other 2% are permabanned IRC trolls browsing the forums with a text-based browser written in Ruby on OpenBSD. Oh yeah, we have one guy using WebTV but I banned him because WTF.

mjhay 4y ago
Hadn't heard that one before. Radium's incompetence was really something.
Jolter 4y ago
He may very well have just made that up.
pram 4y ago
Lowtax banned Phoenix/Firebird at one point, early on. He didn’t like people complaining that stuff didn’t render correctly. He only allowed Internet Explorer for some time. It wasn’t funny.

woodruffw 4y ago

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-authentication-via-query-parameters-for-48-hours/ https://github.blog/changelog/2021-08-10-brownout-notice-api...

js2 4y ago
These are also known as scream tests. We use them internally at $dayjob as part of EOL'ing APIs. Are they not common?
- woodruffw 4y ago
  I have no clue! I just appreciated them as a lowly user.
- CodexArcana 4y ago
  Lol brown outs is such a nicer name, but I've always known them as a scream test.
  - adamckay 4y ago
    They're ever so slightly different. Scream test is to discontinue service entirely and see who screams, akin to pulling the plug on a server in a rack when you've got no idea what's running on it, to then plug in back in when you find out it's the finance team running payroll software. Brown outs are typically short-lived purposeful errors or aborts to either shed load to prevent a failure due to capacity exhaustion or cause issues that are investigated by a human to find the service has been sunsetted which raise awareness that something needs to be fixed before it's totally broken.
travisjungroth 4y ago
Make sure to get the rate right. Like 1/1,000 or 1/100,000. Poetry did a brownout of its install script at 5% failure. With a matrix of builds user's CI had closer to a 100% chance of failing.

singularity2001 4y ago

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

_da_ 4y ago
> 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 workflows.
- jeppester 4y ago
  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.
  - WorldMaker 4y ago
    If you are already using GitHub you can write your own short scripts with GitHub's file raw URLs (which include a specific commit hash) and curl/httpie. Obviously, that's not easily portable to other hosts (though most of the big ones have similar URL patterns that you can discover), but depending on your use case may be a handy option. > But it still comes with git - which I'll then have to remove for my use case. I don't know what your use case is, or why you don't have a local history anyway of the repo so that you need to spot-download sub-trees, but if this is a somewhat common workflow this seems to indicate you may possibly be looking for something like git-archive [1]. That's a tool included in the "corners" of the git "suite" to take a `treeish` and build a tar or zip directly from it (with no git metadata inside). You can use a commit or a tag name for a `treeish`, but if you wanted it to be a specific folder inside a commit you can pull the commit, examine the tree it points to until you find the tree ID inside that representing just the subfolder you are looking for. You can pass that tree ID to git-archive. (And other things that take a `treeish`.) It's not quite a "completely trivial oneliner" to write a script to do that, but it may not be that much more complicated of a script to write. [1] https://git-scm.com/docs/git-archive https://git-scm.com/docs/git-archive

lopkeny12ko 4y ago

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

sastraxi 4y ago
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.

renewiltord 4y ago

I had no idea. This is fucking great. Hahaha. Best thing I've read all day.

neallindsay 4y ago

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.

yoden 4y ago
> 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. 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.
- neallindsay 4y ago

issafram 4y ago

This part made me laugh "Late in 2023, we’ll run a few hours-long and then day-long brownouts to help flush out any remaining use of the feature." I'd prefer just spam emails saying the system is shutting down

Aachen 4y ago
And after the email spam, it just shuts off? Wouldn't a temporary outage be a better way to attend those not reading the old email box used to sign up for Github that they need to upgrade their software?

bradfitz 4y ago

They had Subversion support?

SeanLuke 4y ago

<sigh> I still use the svn bridge as my primary way to acces GitHub repositories: I get around much faster in svn than in git and have little need for a VCS except in special circumstances. Kinda dreading this.

jesuspiece 4y ago

When are we going to admit to ourselves that everything else is worse than git?

xerxesaa 4y ago

In the many years I've used github, I honestly never even realized they supported svn.

therufa 4y ago

what does sunsetting mean?