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:
  • by barlevg (2111272) on Tuesday April 01, 2014 @12:04PM (#46631551)
    In related news, Microsoft will be using Gmail for their company email, and Apple will be replacing their workstations with Linux boxes.
  • Subversion is really a joke. Gotcha!

    • 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: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: (Score:2, Insightful)

        by Anonymous Coward
        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: (Score:3, Informative)

          by EvanED (569694)

          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

          • by madprof (4723)

            My team wanted to use bookmarks instead of HG branches. Sadly our version of Rhodecode did not support them. So we've moved the team to Git and it's actually turning out OK. Yes, different and I miss the simplicity of HG and the lovely logical nature of it. Git feels more inconsistent. But it's doing the job.

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

        by Wootery (1087023) on Tuesday April 01, 2014 @12:55PM (#46631927)

        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! (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.

          • by jythie (914043)
            I keep hearing this, but so far I have encountered about the same amount of branch conflict in git as I have with SVN, just with the added complexity of local repo vs checkout. But I have not found any magical advantage in its ability to merge a file that has been changed by two different developers.

            Branching does not seem any harder or easier.
            • by Dynedain (141758)

              The difference I've seen is that Git doesn't fail miserably and corrupt your local repository tracking info the way SVN tends to.

              • by gatkinso (15975)

                Ha! I see just the opposite: git fucking up miserably to the point where a dev has to locally pull their changes, reclone, and overlay the changes... where svn I have never seen that.

                Of course when the network goes down, so does svn.... choose your poison.

                • by Dynedain (141758)

                  Try deleting a local folder without deleting the subfolders (and committing) first. Instant corruption in SVN.

                  Move a folder (with subfolders). Instant corruption in SVN.

                  Since Git (and Hg) do a diff of the entire checkout rather than maintaining meta deta per directory, it's a lot easier to do refactoring without screwing things up.

                  • by gatkinso (15975)

                    It is true, you must use "svn mv" as opposed to "mv."

                    The horror.

                    • by Dynedain (141758)

                      Yeah, try teaching that to people who's job is to do front-end development or other tasks where the OS GUI is the right tool, not the command line.

                    • by gatkinso (15975)

                      TortoiseSVN (for example), right click drag, drop, select SVN Move versioned files here. That was exhausting.

                      So much worse than when, say SmartGit, gets stuck in an endless rebaseing state thereby complete fsking your local repo along with any stashes you may have.

                      But this is what you get for replying on a GUI.

                      However most GUI devs I work with (myself included) operate from the command line.

                    • by gatkinso (15975)

                      Replying on a GUI. Jesus wept.

                    • by Dynedain (141758)

                      Or you know, just drag and drop using my existing filesystem viewer and not need a special client to do something simple like renaming a folder.

                      Nothing like reinventing the wheel!

          • by jeremyp (130771)

            I keep hearing the "git is better than svn at handling conflicts" meme, but of course neither handles conflicts at all. A conflict is a file where the tool can't figure out how to merge two versions and therefore has to offload it to a human.

            I've also heard on the Internet that git is better than svn at doing merges, but everybody I know who has used both git and svn in real production environments says the opposite.

            In my company we use svn. I did consider moving us to git or - more likely - Mercurial (th

        • (Technically, as Git is SVN compatible, so you could get this effect simply by using Git 'locally'.)

          git2svn has a problem that we ran into recently: because git does not support hierarchical branching, if you do not keep all your branches in a single Subversion directory, it will take an excessively long time for a local git repository to synchronize with a Subversion repository.

          For example, let's say that you have the typical /branches directory in Subversion. Now user "myria" comes along, and she wants to make her own directory of branches so that her own branches don't pollute the /branches directory.

          • git does support hierarchical branches. You can have a branch named maria/new-crypto, and even pattern-match on the branch path in refspecs. The problem, as you alluded to, is that SVN doesn't have native branches at all, just copies. How is git-svn supposed to know that /branches/maria/new-crypto refers to a branch of /trunk and not to a directory within the "maria" branch? They look the same. For that matter, you could get that path by creating a branch named "maria" (copied from some version of /trunk) a

      • by jythie (914043)
        Let the religious wars begin!

        In all seriousness, SVN and git have strengths and weaknesses depending on the project and its needs, though usually the biggest one is going to be 'what do your developers already know'. Git was built to support distributed projects and is really strong in those cases, SVN was built to be highly centralized and administered and tends to be stronger when that is the plan. For most small projects they are functionally equivalent, well, outside git's 'local repo' system, which
        • by gatkinso (15975)

          I thought svn was developed to fix the problems with cvs... which it has mostly accomplished.

      • by Dynedain (141758)

        As someone who uses SVN, Git, and Hg in a corporate environment (plus we have the MS solution around here somewhere but I don't touch it), I love using Git or Hg. I've setup some pretty complex project structures and branch behaviors that take advantage of how the different systems work.

        That said, I haven't seen anything that would distinguish Git over Hg (or the opposite) when used in a corporate setting. If you like Hg over SVN, then you'll like Git as well because it behaves pretty much the same way, jus

        • by hibiki_r (649814)

          The main practical difference, past the API, is their approach to branching: A git branch is a mercurial bookmark. There are no concept like mercurial's branch in git. There's also how git has this crazy staging area that is the cause of 90% of bad commits to our git repos. Commits that are missing a file, or have an extra file, are the bane of SVN and Git repos. In hg, the expected behavior is commit everything that is not in a patch. More discipline required, less chances of shooting yourself in the foot.

      • by Zebedeu (739988)

        I've used git in a traditional corporate environment, and done right, it can be a lot more powerful than SVN.

        "Done right" means you have someone dedicated to the role of "git master" who merges the team's commits into the master repository.
        This is what Linus does, and it works to great effect. The great advantage is that individuals and teams can very easily work on their private branches before merging into mainline.

        The second method is to set up a server which runs automatic tests on all commits and guara

        • by Anrego (830717) *

          "Done right" means you have someone dedicated to the role of "git master" who merges the team's commits into the master repository.

          I would argue that this is a good practice with svn as well. You can have a free-for-all dev branch, or even a whole dev trunk, but having someone at the top (some kind of coordinator.. of builds..) makes a lot of sense.

          The second method is to set up a server which runs automatic tests on all commits and guarantees at least that the git history remains clean and contributions do not break the build.

          Again, this is in no way git specific. Commit hooks are well supported in svn, and tools like hudson and jenkins handle continuous integration with svn just as well as with git.

          Personally I'm an svn fan, but I think with both it comes down to using it appropriately.

          My main argument for svn i

          • by Zebedeu (739988)

            Again, this is in no way git specific. Commit hooks are well supported in svn, and tools like hudson and jenkins handle continuous integration with svn just as well as with git.

            It wasn't my intention to imply that these techniques are unique to git.
            The original poster mentioned liking SVN better because of the command structure, and I was pointing out that that's possible as well with git. My point was that for certain corporate environments (or large teams in general) git can be made more centralized without losing many of its benefits.

      • by gatkinso (15975)

        I use both git and svn heavily. They both have strengths and shortcomings. Git has far stronger merge and is very useful if you are a dev who has to be disconnected for any period of time. Svn is far easier to maintain from an admin point of view and is far simpler.

        Choose your poison - both seem to work fine.

      • by madprof (4723)

        As someone who moved from SVN to HG and now from HG to Git for the same codebase, it's quite a natural step.
        The HG to Git move was because of branching behaviour, which we preferred in Git, plus the ability to use Stash.
        Git has its quirks but I'm having zero problems moving.
        I'd always always go with HG over SVN, any day of the week and twice on a Sunday.

      • by orasio (188021)

        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.

        I am working in a traditional corporate environment right now.
        SVN sorks great, even when you use branchs. The problem is that merging is just not worth it.
        Right now, we use SVN, and the equivalent of a pull request in github or similar, is a manual process, with several pain points, that works against the grain of development. We need to have separate code reviews for commits, and then count on developers merging code that is accepted.
        We also have problems creating branches, destroying them.

        I think SVN was

      • by tibit (1762298)

        First of all, I don't think that it's sane to use svn or git without a graphical front-end. That said, I find that git-svn works way better than svn itself. Subversion merging starts looking downright silly once you see how git does it. And I was one of those who actually argued that svn's merging is "good enough". Eventually I convinced myself, through experimentation, that it's nowhere near good enough. To me, subversion is a way of centrally storing git repos without having to configure server-side git,

      • Our project's team decided to move from SVN to Git a few months back. We develop for .NET and were all used to working with TortoiseSVN with code being managed on a server which could control access to different repositories.

        We had one guy who recently joined our team who knew Git and felt it was worth taking the plunge and moving to it, acknowledging that we would initially be frustrated at having to learn a new tool.
        We use TortoiseGit along with Gitblit [gitblit.com] to host the repositories and at this point I hav
  • Ahahaha (Score:2, Funny)

    by Anonymous Coward
    See, what they've done here is concocted and published an implausible story (or in this case, tracking issue) that is designed to misdirect, nay, fool people into believing it is real. These jolly japesters have done this in the full knowledge that it will mislead people into believing it to be true, and they have chosen to do it today, on the very first day of April, as is customary in these matters.

    Oh Apache and Slashdot, you are truly such ruse masters!

    Seriously, April 1st is such a fucking bag of sh
  • 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.

    • by javilon (99157)

      The day git implements subversion externals functionality so it is easy and risk free to update from and commit to external branches, I'll swich my team. Git modules functionality is close, but you can make a mess if you commit while having a module set up.

      • by stoploss (2842505)

        The day git implements subversion externals functionality so it is easy and risk free to update from and commit to external branches, I'll swich my team. Git modules functionality is close, but you can make a mess if you commit while having a module set up.

        Okay, I admit to not fully researching this, but because I have found svn externals useful in the past I thought I would inquire.

        Is this something repo (used in the Android Open Source Project, I call it "meta-git") could handle? From my experience with it, repo did many of the same things I would have used a svn external for. I admit the workflow for repo didn't seem very polished, but it did allow AOSP/CyanogenMod to meta-version various git repos for a build.

        Secondly, if you dont mind going into detail,

  • Hmm (Score:4, Informative)

    by Anrego (830717) * on Tuesday April 01, 2014 @12:10PM (#46631603)

    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: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.

      • by EvanED (569694)

        Yeah it got me for a good bit too. I was about to go post it to a chat in a making-fun-of-SVN-way at which point my brain was like "waaaaiiiit a minnnute..."

      • by hagnat (752654)

        unlike other years, this time slashdot has been low on april fool articles... so i was fooled as well XD

      • by Bengie (1121981)
        Didn't fool me. Subversion wouldn't be eating their own dog-food and that would reduce their ability to properly expand it. What better testing of something than to actually use it day-to-day? This would akin to Linus using FreeBSD. He would start to lose touch.
        • by Anrego (830717) *

          Honestly I think it's way more political than practical.

          Tools tend to have use cases that they are more suited to, while having use cases that their competition is more suited to. It's not unheard of to actually fall into your competitors use case while developing a product that competes in some other use case.

          Politics however will almost always force you to use your own products when it's an option, even if it's the worst option.

          Also I think if I use the words "use case" one more time today I fear I might

          • A good example of this is Xero (accounting software company) who recently had to stop using their own software because they got too big - way, way too big - but they hung in for a long time because they didn't want to be a company that didn't use it's own software.

      • by D. Taylor (53947)

        I'm voting for (a) with a helping of very-not-(c), given:

        - the comments on https://issues.apache.org/jira... [apache.org]
        - this story http://www.infoq.com/news/2014... [infoq.com]
        - and this twitter conversation https://twitter.com/gstein/sta... [twitter.com]

        • by mooingyak (720677)

          So this is either legit or an absolutely brilliantly executed joke.

    • Everybody in that issue, except for three, .. were part of our coordinated effort. Two people threw in comments that we had to delete (and if you look closely, are in the history). The third was likely aware, and his several comments supported our ruse, so they remained.

      Our various tweets, including the two from @TheASF were (of course) coordinated along with the movement on the issue.

      It was about a dozen of us, spanning around 14 hours. Many April Fool's pranks are "fire and forget". Keeping it *live* was

      • by Anrego (830717) *

        Thanks for the followup :)

        And let me say I was legitimately blown away by this. I was totally convinced this was an April fools joke in the morning, but as things progressed I was starting to have doubts. By the time the proverbial beans were finally spilled, I was honestly giving it 50/50 of being real with very poor timing. You guys totally sold it.

        Definitely the best prank I've seen in a long time. Much appreciated :)

         

  • Really?
  • by Anonymous Coward

    ...as wishful thinking I am guessing.

  • Change (Score:5, Funny)

    by Yunzil (181064) on Tuesday April 01, 2014 @12:23PM (#46631715) Homepage

    'this [migration] will finally let us get rid of the current broken design... ... and replace it with a completely new broken design. (I hate git.)

    • by caseih (160668)

      What specifically don't you like about git? How is it a new broken design? Is it broken because it does not fit with your work flow or handle certain types of development? Curious to know.

      • Not the OP here, but the main thing I dislike about git is the UI. The internals may be good, but the UI is a hack, complete with counter-intuitive alternate uses of commands via switches that seem like they should be used elsewhere, etc., etc., etc. Contrast that with Mercurial, which has a much more logical and consistent UI, and UI's are important (command line or of that other trendy variety). People who think the git UI is fine are probably just used to it. If you can get used to the spelling of my mot

      • by enigma32 (128601)

        +1 UI madness.
        For me the problem with git is the extreme un-usability of the standard command-line client.

        There are countless ways of doing the same operations, all of which are confusing. Unless I use a specific command on a daily basis I end up having to look it up and sift through results with varying ways of doing the same thing. It is extremely frustrating. Some of the other dvcs solutions are far superior in this regard.

        Architecturally, git is fantastic. It seems to me it shouldn't be that difficult t

        • Re:Change (Score:4, Funny)

          by BlackPignouf (1017012) on Tuesday April 01, 2014 @02:28PM (#46632813)

          Exactly.

          I love git, because all my development repos are self-contained, easy to backup and work perfectly offline.
          "git rebase -i" is just wonderful.

          BUT :
          You want to pull and overwrite your local changes? It's as easy as :

            git add *
            git commit -a -m "auto dev server commit"
            git fetch origin master
            git merge -s recursive -X theirs origin/master

          You want to clone your local repo to a new remote one and use it as origin? Sure :
          #On local machine
          cd foo_project
          git init
          git add *
          git commit -m "My initial commit message"
          #On remote machine (Git remote repository)
          sudo su - git
          cd /usr/local/git_root/
          mkdir foo-project.git
          cd foo-project.git/
          git --bare init
          git config core.sharedrepository 1
          git config receive.denyNonFastforwards true
          find objects -type d -exec chmod 02770 {} \;
          #On local machine, in your git project
          git remote add origin ssh://git@example.com:2227/usr/local/git_root/foo_project.git
          git push -u origin master

          Those are just 2 examples that come often enough to be an annoyance, but not often enough that I can remember them.

      • by Yunzil (181064)

        Terrible, unintuitive syntax. Horrible documentation that was apparently written for people who already understand it. Obscure error messages. Too much knowledge required up front to start using it effectively. Hard to pick up the pieces when something inevitably goes wrong.

        I've seen posts elsewhere where people say "Oh, once you understand that behind the scenes it's working on blobs and trees and commits then it makes more sense. Also, graph theory." OK, but should I need to know any of that? I don

        • by tibit (1762298)

          OK, but should I need to know any of that?

          Yes. I've found that there's no way to use it without knowing this. It's as simple as that, and I don't consider it a deficiency of git at all. You're supposed to understand the tools that you use. The things you speak of are not implementation details, they are part of the semantics exposed directly to the user. They make the whole thing work and useful.

          Yes, the command line syntax is abhorrent, but then I almost never use it. SmartGit/Hg [syntevo.com] has won me over.

  • Not as bad as some of the jokes in years past.

  • 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!
    • by Nimey (114278)

      I don't miss those days when every goddamn post on 1 April was an unfunny joke.

    • Nah, they're just lumping April 1 and April 20 into one event: an Easter Egg hunt for April Fool's jokes.

    • by sootman (158191)

      You've got it exactly backwards. The whole point of April Fool's is to -- get this -- FOOL people. So instead of a bunch of OBVIOUSLY wrong stories that fool NO ONE (and are totally un-funny to boot), you sneak in one or two plausible-sounding stories among the rest and fool people.

      In other words, Slashdot doesn't want to just list a bunch of jokes that other people made -- they want to play some tricks themselves.

      I much prefer this to "shitty jokes that make Slashdot totally unreadable" day.

  • by Anonymous Coward

    and CVS migrates to RCS supported by front end in Gopher, a backend in TFTP with all discussions held over usenet using the pine news reader. If everyone would just remember to update the damn version numbers.

  • The best thing about April 2 is that all those fucking stupid joke stories start to scroll off of the site.

    The worst thing about April 2 is that those fucking stupid joke stories haven't yet fully scrolled off of the site.

    I would REALLY love for Slashdot to have a new option: hide April 1 joke stories.

"'Tis true, 'tis pity, and pity 'tis 'tis true." -- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

Working...