Slashdot Mirror

← Back to Stories (view on slashdot.org)

Subversion Project Migrates To Git

Posted by timothy on from the seasonal-variety dept.

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.

2 of 162 comments (clear)

  1. Re:April Fools! by Wootery · · Score: 4, Informative

    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.

  2. Re:April Fools! by jythie · · Score: 4, Informative

    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.