GitHub Sunsetting Subversion Support
71–80 of 238 posts
Re: GitHub Sunsetting Subversion Support
#72As 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…
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. )
Re: GitHub Sunsetting Subversion Support
#73I'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.
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…
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 branches and such were _instant_ instead of many seconds, and I could work more flexibly (git doesn't require being connected to the server).
Re: GitHub Sunsetting Subversion Support
#74As 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…
Re: GitHub Sunsetting Subversion Support
#75I'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 use Subversion at my gig in several places. I don't use it to manage source code revision control, but I have several processes that require business users to manage binary files (such as audio files) in order for them to be automatically deployed to production. Git or Mercurial are pretty awful at this kind of role. Subversion let's me check out at a subfolder level of a repository, and not pay the cost of having…
[1] https://github.blog/2020-12-21-get-up-to-speed-with-partial-...
[2] https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...
Re: GitHub Sunsetting Subversion Support
#76Earlier quoted context omitted.
SVN is a relatively sane option, especially before git was published. But in 2023 its mostly been replaced.
Subversion fixed all the truly horrific things about CVS, it's quite adequate for centralized source control.
> I see Subversion as being the most pointless project ever started, because the slogan for Subversion for a while was "CVS done right" or something like that and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.
Re: GitHub Sunsetting Subversion Support
#77Is there an alternative way to download select folders without svn?
Re: GitHub Sunsetting Subversion Support
#78Not 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.
Re: GitHub Sunsetting Subversion Support
#79There 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.
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.
Re: GitHub Sunsetting Subversion Support
#80How about Visual SourceSafe? I actually loved that for a small team.
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.