Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

Moving to GitHub?

Filed under: Uncategorized by guenter at 10:33

Since a few people have suggested moving the project to GitHub, I am willing to give it a try. Before doing so however, I’d like to collect some input and feedback. First, how should we set up the project on GitHub? The simplest way would be to move the entire SVN tree (with trunk, sandbox and all branches) to GitHub. I don’t really like the idea, as there’s no need to move the old release branches over to GitHub. Also, some parts of the SVN repository (sandbox) could need some cleanup. The other issue is that I plan to integrate the changes from the 1.3.x branches into the trunk. How can we set up the Git repository, so that this integration can be easily done? And finally, are there any specific things to take care of? Best practices?

9 Comments »
  1. You might want to check out the MongoDB project. They are probably the biggest C++ GitHub project. See how they have integrated their bug system, jira.mongodb.org, and github together.

    Also they do have donation badges, so you can put that on there too. Basically what happens, it will take time, is after you get going, people can easily fork off your project make changes and send you a push request. Also, you might want to contact the GitHub guys and I am sure they can feature you on the front page of GitHub, great way to gain traction.

    GitHub will also highlight your repository in the trends pages as you guys checkin, so they do a lot of pr for the project. Overall the system is slicker and I think over time it builds more interest in the project, something that SourceForge simply does not provide.

    Comment by Devin Akin on February 11, 2010, 11:35

  2. Maybe you can start with moving the Sandbox to git and create the Poco Code project as mentioned on poco-develop mailing-list? This way we can can all get familiar with git. I don’t know git and don’t know how well it can be used on Windows, which is my main development platform for now.

    Comment by Franky Braem on February 15, 2010, 07:38

  3. I think you should consider using Mercurial as another option. I’m not saying one is better than the other, but there seems to be some kind of hype around Git, and I believe Mercurial well deserves to be used as well.

    Here’s a site that provides hosting (which seems to be better for the free version)
    http://bitbucket.org/plans/

    Or why not set up the repository on Applied Informatics’ servers?

    ————————————————–

    “I don’t really like the idea, as there’s no need to move the old release branches over to GitHub.”

    Just move a few of the most recent branches, trunk, and the sandbox.

    “How can we set up the Git repository, so that this integration can be easily done?”

    Merging is supposed to be easier with a DVCS (Distributed Version Constrol System) than SVN.

    ————————————————–

    As Franky Braem said, perhaps you could just start off with the sandbox, and in a few weeks (or months) move the rest, after further discussions (such as what exactly to move, whether to use git or mercurial, etc)

    Comment by Aurelien Derouineau on February 16, 2010, 10:18

  4. I’ve been using github for a month now and the barrier to forking changes off another project, making changes and then having those folded back into the main project is so low it is amazing.

    I’m a complete git convert :)

    Comment by Brad Phelan on February 16, 2010, 15:31

  5. I have not seen it mentioned, but I trust you ARE aware of the “git svn” commands? These make it pretty easy to pull the revision history, tags, and branches that you actually want out of svn and into a new git repository. You can experiment with this locally. Then, once you have a git repository that fits your requirements, clone it over to GitHub.

    Comment by Brian Holdsworth on February 17, 2010, 18:29

  6. The problem is not how to move a SVN repository to GIT. git svn and GitHub do a fine job with that. The actual problem is that we now have two separate POCO branches – the Trunk and the 1.3.7 branch. At one point in the not so far future, we’ll integrate the changes from 1.3.7 back into the Trunk, then create a 1.4 branch. The question now is, how should we set up the trunk and 1.3 branches in GitHub, in a way that would allow for easy merging at a later point.

    Comment by guenter on February 17, 2010, 18:37

  7. guenter,

    I suppose, from what you’ve been saying, that you’re already set on git and do not wish to consider hg (mercurial)…

    Comment by Aurelien Derouineau on February 18, 2010, 01:19

  8. Personally, I have no preference for git over mercurial (or vice versa), it’s just that most people who have commented seem to prefer git. From what I’ve seen from various sources, feature-wise git and hg are basically on par. GitHub seems to generate more hype at the moment, which may benefit the project. Anyway, if anyone knows a compelling reason why we should prefer hg over git, I’m open.

    Comment by guenter on February 19, 2010, 10:09

  9. As you say, it’s more of a hype, really. Many people hear of git and not hg, so they use git and talk about it, etc. (Ruby On Rails got such hype, and it’s not that popular anymore)
    One of the main differences between the two is that git is a bunch of small “scripts” while hg is one big script. Some prefer the former; I prefer the latter. Just like github, bitbucket features projects on its main page; and advertisement can also be obtained by posting on forums and on the web.

    Have a lot at differences here: http://code.google.com/p/support/wiki/DVCSAnalysis

    Since POCO is a multi-platform library, it would be logical to use a purely multi-platform DVCS: Mercurial.

    Comment by Aurélien Derouineau on February 23, 2010, 03:56

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment