21–30 of 238 posts
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.
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 > In 2010, when GitHub introduced Subversion support, the version control landscape was very different. That was waaaaay before Microsoft acq…
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.
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…
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…
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.
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 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.
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.
SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.
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.
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.
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…
How about Visual SourceSafe? 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).
Earlier quoted context omitted.
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-...
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.
You could tag, but then you are just polluting your tag namespace with old branches.