Subversion Project Migrates To Git

New submitter gitficionado (3600283) writes "The Apache Subversion project has begun migrating its source code from the ASF Subversion repo to git. Last week, the Subversion PMC (project management committee) voted to migrate, and the migration has already begun. Although there was strong opposition to the move from the older and more conservative SVN devs, and reportedly a lot of grumbling and ranting when the vote was tallied, a member of the PMC (who asked to remain anonymous) told the author that 'this [migration] will finally let us get rid of the current broken design to a decentralized source control model [and we'll get] merge and rename done right after all this time.'" Source for the new git backend.

Hmm

[Anrego]

I've got to admit. The discussion going on in that ticket is pretty convincing, leading me to think that either:

a) legit
b) they sucked in a lot of their own people
c) really well thought out

I'm thinking (and hoping) b, with c as an unlikely but possible second.

Re:April Fool's!

[lgw]

Apple seriously uses Outlook Exchange for their mail servers, though.

[Archer]You can just say "Exchange"[/Archer]

And the iCloud is stored on Azure. The whole "Onion or Reality" test can be difficult in tech these days.

Re:April Fools!

[Wootery]

Disagree. I've seen Git used to good effect in a traditional corporate environment. The ability to quickly make your own branches is useful, even if there's just an SVN-style single trunk of proper code-reviewed commits. (Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)

The ability to make team-specific branches is also valuable: a team can work toward a feature using a team-local branch, and only once they're done, rebase and push their work into the the trunk. (Yes, rebasing might take work, but it can be beneficial to just 'do this all in one go' when the team is done implementing the feature, as it means the ground isn't moving beneath their feet during 'proper' development time.)

Git does everything SVN does, and an awful lot more - personally I'd only even consider going with SVN if there were a developer team who only knew SVN and didn't have time to learn Git.

Don't know much about Mercurial, but I'm sure it's good too.

Re:April Fools!

[EvanED]

The only reason I can come up with Gits popularity over Mercurial is that Linus wrote it.

You may be partly right. But I think a lot of it is that for a while, Git was a lot more "powerful" -- it supported some very useful modes of operation that Hg either didn't have or wasn't very good at. So while Git was confusing, once you learned the model and commands it did a really good job of rewarding you for it.

This gap has closed substantially, particularly on the Hg side -- a lot of the "missing features" have been implemented either in core Hg or in extensions. At the same time, Git has been doing a reasonably good job at improving usability, though some issues remain.

Then again, I'm a Git user who hasn't worked much with Hg, so take what I said with a strong dose of salt.

Re:April Fools!

[jythie]

That strikes me as an issue with your server, not SVN. I have worked on projects where SVN handled tens of thousands of files, dozens of branches, thousands of tags, etc, and found syncing to be pretty reasonable. In fact we switched over to SVN in part because Clear Case was having trouble keeping up with the volume.