Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming Software Apache

Subversion Project Migrates To Git 162

Posted by timothy
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.
This discussion has been archived. No new comments can be posted.

Subversion Project Migrates To Git

Comments Filter:
  • funny thing is (Score:5, Insightful)

    by epiphani (254981) <epiphani.dal@net> on Tuesday April 01, 2014 @12:09PM (#46631599)

    This would probably be a good idea for the future of subversion.

  • Re:Hmm (Score:4, Insightful)

    by mooingyak (720677) on Tuesday April 01, 2014 @12:26PM (#46631737)

    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.

    I'll confess I was fooled until I remember what day it is.

  • Re:April Fools! (Score:5, Insightful)

    by Anonymous Coward on Tuesday April 01, 2014 @12:31PM (#46631765)

    I've never understood the popularity of git. It may be useful for open source by supporting distributed development but it seems far less useful for a traditional corporate environment. SVN just makes far more sense to me in terms of command structure. If I wanted a DVCS I would probably go with Mercurial. Git is just awful.

  • Re:Hmm (Score:4, Insightful)

    by mooingyak (720677) on Tuesday April 01, 2014 @12:36PM (#46631793)

    Yeah. They're doing it right, finally.

  • by markhb (11721) on Tuesday April 01, 2014 @12:42PM (#46631821) Journal
    ... when Slashdot posted nothing but joke stories all day on April 1; it was the best way to catch all of them. Maybe they decided they couldn't top themselves after OMG PONIES!!!!! (which I missed), but just sticking in one joke stories amongst a bunch of uninteresting real ones is lame. There isn't even an article on the Google prank!
  • Re:April Fools! (Score:5, Insightful)

    by lgw (121541) on Tuesday April 01, 2014 @12:51PM (#46631891) Journal

    Git solves one incredibly important problem: it stops "Linux kernel commit privileges" from being a constant political battle on Linus's part. By making "official builds" pull based, instead of push based, the whole question of "who gets to commit" vanishes and Linus has full control by change, instead of by author - a far less emotional and political thing.

    So Git is overwhelmingly better if you're Linus Torvalds. And, hey, that's how open source gets written. If anyone else finds it useful for anything, that's just gravy.
     

  • Re:April Fools! (Score:2, Insightful)

    by Anonymous Coward on Tuesday April 01, 2014 @12:55PM (#46631925)
    I, too, was happy with Mercurial and wonder why Git is so popular. I find Git inconsistent and confusing, and it seems to implement the idiom of most-surprise: that is, whatever a command does by default is probably not what you wanted, and the way to do anything you might consider simple is complicated.

    The only reason I can come up with Gits popularity over Mercurial is that Linus wrote it. That's about it.
  • Re:April Fools! (Score:5, Insightful)

    by Anonymous Coward on Tuesday April 01, 2014 @01:25PM (#46632117)

    discovering git- but I'm actually curious what is awful about it?

    Linus's decision to screw over everyone that has ever used SCM by refusing to use normal terms is the most awful part. Instead, as he admitted, he just randomly assigned words to concepts. For example, he randomly picked the word checkout to mean revert. Ditto using the word reset to mean unstage. "git pull" refuses to update the source like a normal system would. Instead you have to do the "git stash; git stash apply stash@{0}" dance. And stash/unstash is not standard in the first place since Bazaar, Mercurial, Perforce, TFS, etc. use the terms shelve/unshelve. The word clone is another odd one. On the topic, the decision to not allow clone to checkout a subset of a repository like is often done with Subversion is a curious one. Another not understanding users is the decision to disallow checking out only the current version of all files rather than every single version of every single file.

    His decision to add so many dependencies to make it difficult to run Git on anything but Linux is another awful decision. The msysgit directory on Windows contains 14,589 files in 622Mbytes. A simple SCM should not require over 14,000 files! Finally, the decision to make the server side weak, especially wrt security, is also awful. As Linus admitted, his belief is that you should give everyone full access to everything. That obviously doesn't scale.

    Of course, everything below the covers with Git is spectacular. We use it for a 500k file repo, and have had no problems after nine months. Before converting, our developers were wasting hours a week running "svn cleanup." Our artists are converting to it from Perforce, and other than the stupid decisions on command names and decision to not allow checking out just HEAD or a subset of the repo, they've had no problems despite working with hundreds of multigigabyte files.

  • Re:April Fools! (Score:4, Insightful)

    by sam0ht (46606) on Tuesday April 01, 2014 @01:27PM (#46632131)

    I use Git to good effect in a fairly traditional corporate environment. We're much better off since switching over from SVN.

    Never mind the 'distributed' part - the big challenge for source control in a traditional setup is when two people have both modified different parts of the same files, and the second guy goes to check in. Git is much better at handling conflicts than SVN is - conflicts that would cause real pain in SVN often merge smoothly in Git.

    It's also much better at handling branches, e.g. a release branch. Remember 'tree conflicts' in SVN? Not an issue in Git.

    Git is a better SVN, as well as being a distributed source control system.

  • Re:April Fools! (Score:5, Insightful)

    by EvanED (569694) <evaned@ g m ail.com> on Tuesday April 01, 2014 @01:42PM (#46632245)

    For example, he randomly picked the word checkout to mean revert

    That choice actually makes sense from the Git model. A Subversion person would ask why there is one command for three+ different things (svn revert, svn switch, svn up -r### are all done using git checkout). But if you turn your head around and look at it from a different perspective, all three of those are doing the same thing: copying something from the repository store to the working copy. From the Git perspective, Subversion is giving three different names to the same thing, each of which only works some of the time.

    I don't want to argue Git is right, just that if it has a fault here, Git's is that its terms are at a lower level than users usually think and not that it's inconsistent on this point.

    Ditto using the word reset to mean unstage.

    Oh boy. The whole index is a mess of inconsistent terminology. You stage something to the index using git add, unless you're using git add --interactive in which case that process is called updating. And of course you see what the changes are in your index by using git diff --cached. Wut?

    (Yes, I know, git diff --staged is now an alias for the last. Good, now all they have to do is deal with the three other synonyms for the same thing.)

    "git pull" refuses to update the source like a normal system would. Instead you have to do the "git stash; git stash apply stash@{0}" dance

    Here I also defend git, because I think this is a significant selling point. One major advantage that Git has is that once something is actually added to the store, it's nearly impossible to accidentally lose information. git stash adds the state to the store.

    Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.

    Compare to git. You have to run stash before pulling (merging/rebasing technically of course), so now the state of the working copy right before the pull is in the store. You then stash apply. You get the conflicts, say "I give up for now". Now all you have to do is figure out what the SHA1 of the copy that was in the stash is. Might have to do some reflog digging, but it is not only possible but actually pretty easy if you know about the reflog.

  • Re:April Fools! (Score:5, Insightful)

    by jythie (914043) on Tuesday April 01, 2014 @02:02PM (#46632471)
    I can answer at least some of that. I am a long time SVN user who is now using git, and while I would not call it 'awful', I do find the 'local repo' structure to be frustrating and needlessly complex, and generally comes across as over-engineered. Kinda like ClearCase, it can handle more complex situations then SVN, but that additional support causes complexity to seep into simpler cases.

    I have also had difficulties with the client that I never had under SVN, with pretty much no luck with it working 'out of the box' on any of the machines I use. So in each case I have had to install the full development chain in order to rebuild the client because the one already installed is incompatible. SVN, for all its dullness, tends to be pretty conservative about changes and generally the distro installed one works.

    However, for my use case, the community aspect (i.e. the finding projects) and traveling are not important, so those advantages do not get me much.
  • Re:April Fool's! (Score:3, Insightful)

    by tlhIngan (30335) <[ten.frow] [ta] [todhsals]> on Tuesday April 01, 2014 @03:21PM (#46633553)

    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.

    Well, given Apple's not exactly a well known entity in the MTA market, or in the cloud computing market, I don't see the big deal that they're using Exchange and Azure.

    They're both good products run by people who know what they're doing. At least, know more than Apple on those topics. And neither is something Apple wants to get in and support directly. I mean, yes they could do it, but I suspect that Microsoft simply does it better and probably more securely than Apple on their own.

  • Re:April Fools! (Score:4, Insightful)

    by Anrego (830717) * on Tuesday April 01, 2014 @04:15PM (#46634113)

    Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.

    Totally this. As a subversion fanboy who has yet to jump on the git train, I see this as one of the major oversights in svn.

    Personally I'm a fan of one developer, one branch. It's a bit of overhead for sure, but everyone having their own branch where they can check in their changes before merging in changes from the main branch is a nice safety net. You just have to learn to reintegrate to the feature branch often to avoid silo effect.

"In the face of entropy and nothingness, you kind of have to pretend it's not there if you want to keep writing good code." -- Karl Lehenbauer

Working...