SVN vs git on github

We're thinking about switching from SVN to git hosted by github.  Any community thoughts on this?

  • @brett regarding your comment on branching in Git and that feature making it easier for us to commit changes to be considered for the core, is there any reason why the branching feature in SVN does not meet you needs?

    Also there are many people implementing their own "shelving" method in SVN.  I was first introduced to the concept of shelving with Microsoft's TFS and many poeple have been trying to implement the concept on their own in SVN, Git and other versioning systems.

    Here is one person's write-up on implementing shelves in SVN (the first one I found):

  • I don't think there is a huge difference between the features of SVN and Git.  (I use both extensively)  However, the open source world is moving slowly toward Git. Why?  This kind of community, which has a lot of experimentation by people who don't often know each other, finds value in the distributed nature of Git and the push/pull model.  Yes, this kind of activity can be done in SVN, but it's much harder to do for the average person.

    Beyond those differences, GitHub is also a community of people and a very friendly interface. The reporting tools are very cool and sometimes useful. Visually seeing branching and merging is a very nice feature.

    Especially for plugins, if all core and community plugins had their own projects in GitHub, it would be really great.  People could experiment and then do push/pulls if they wanted.  This would be much better than the current community plugin model where people just release their own new version with very little difference than the original.

    How difficult is it to move from SVN to GitHub?  I took a 4-year old active project, moved everything (including all history!) into GitHub in maybe 5 steps and a few hours.  I have had zero problems from that point onward.  It really is easy!

    Lastly, I have yet to meet someone who moved from SVN to Git who thought it was a bad idea.  It takes a couple of days to get used to the Git commands and distributed model, but after that, it's smooth sailing.


  • Brett - I'm really interested to hear why patches haven't been reviewed much for the past year. I know you mentioned a feature lock down since 1.5 elsewhere but the issue has been around a lot longer than that. In the past I was told it was an issue of too much to do, too little time.

  • As an aside, it is great that we can now see changesets using trac!

  • Technically GITxSVN goes over my head: I am just glad I got SVN working after lots of Tortoise struggle.

    But, as I see it, this discussion is too soon. The main issue is not technical and even not the wastefull community split between Google and here. I think the issue is the hard way to group, contribute and learn around developments.

    Look at the quite solo mod development pattern: 1) initiator develops something, 2) post it, 3) get some feedback; 4) improve a little;..... 5) and back to their own thing ... :(

    Why is there no place for second tier contributers in Elgg? 

    There is one-tier (initiators, like Curverider for the core) and there is third-tier: the crowd. But why no inner crowd with special submission rights? People like Kevin, Jeroen or Cash, with huge proven track-records...well, I would be honoured to have them contribute to my mods. This results that the mods are NOT mine anymore but become Community mods!

    This is the same for the core. The Curverider core team should be expanded by a second tier group: a few inner crowd with high track-records, that may contribute to core, easy ticked off by the one-tier group to get into SVN.

    If we all agree here, I suggest some smart people get together to sketch out the basic functions we need to add to to allow for this workflows?

  • @Tom:

    "But, as I see it, this discussion is too soon. The main issue is not technical and even not the wastefull community split between Google and here. I think the issue is the hard way to group, contribute and learn around developments. [...] Why is there no place for second tier contributers in Elgg?"

    Strong +1, very well put.  Though I think it would be useful to expand on this & have a more extended discussion about it before talking about any specific modifications to

  • Alright...At the end of the day, regardless of who has write commit, we need tools to allow us to use version control.

    Let's get back to the real question--the point of this thread: What are the benefits of using git vs SVN and does anyone have any strong feelings either way?

    I prefer git to svn.

  • @Brett,

    I don't think that the thread has drifted off topic.  Apologies to anyone I misrepresent, but it sounds like the discussion can be summarized as falling into two camps:

    1) People who support DVCS in general and github in particular.  (Mahmoudimus, Josiah, Ed Lyons)  These are "+1" votes.

    2) People who don't have a strong opinion about the technical choice and think that the technical choice will not have much bearing on the issue of community transparency & involvement.  (Cash, Tom, myself)  On the immediate issue, these votes are "-0" or "-0.5" (because we feel the costs of switching that will be felt by Curverider & the community are not counterbalanced by any advantage to the community)

    It seems like the enthusiasm of the "yes" voters about their support is stronger than the "no" voters' enthusiasm about our opposition, which is probably a good enough reason to conclude there is community support for the action.

  • Regardless of which technology we use there will be pro's and con's.  Looking at the google post you mentioned before in git vs mercurial, mercurial won because git has terrible support for windows, and is a bit too much of a techy tool. 

    That said if the development tree of Elgg is going to stay chaotic, then we will need something with less restrictions, like git. 

    In my optinion, the community will deal with whatever you pick.  We could use CVS if needs be.  I would like you to consider Mercurial though.  Just reading the review you suggested sold it to me, for medium size/relatively ordered projects.  I would rather Elgg was ordered, but that really depends on Curverider. 

    Balancing SVN vs GIT, is as simple as simplicity vs complexity.  Thorough take up vs techy tool.  Windoze support vs not (well you can install cygwin et al, but its not exactly straight forward). 

    I think a better question is what is your target audience.  How many of those developers that will want to use the SVN code rather than the latest tarball, will be using linux vs windows, or will be prepared to go techy vs keep it simple.  I suspect Git would have the added bonus of discouraging inexperienced coders from hacking Elgg Core (no bad thing), but may slow down the growth of the Core Development community. 

    I think it's got to be your call Brett, and if it turns out to be the wrong choice, we can change again.  I'm sure there will be another release in 3/4 months, so it's not the end of the world either way.


  • Opening up commit privileges is very unlikely to happen. There are plenty of open source projects that work just fine with the model of developer submits patch, other developers/core team review the patch, core team accepts the patch.

    So far the argument for git is

    1. Brett likes it (which I think should be given weight if he is going to handle integrating community development efforts)

    2. git might make it easier for core team to integrate community fixes/enhancements

    The argument for svn is

    1. It is already there/switching costs for developers and core team to use git

    2. Mahmoudimus said Windows support is poor for git at this point

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.