Comments on: Moving to GitHub? http://pocoproject.org/blog/?p=340 News and discussion for the POCO Community Thu, 09 May 2013 12:05:16 +0200 http://wordpress.org/?v=2.8.5 hourly 1 By: Aurélien Derouineau http://pocoproject.org/blog/?p=340&cpage=1#comment-670 Aurélien Derouineau Tue, 23 Feb 2010 02:56:27 +0000 http://pocoproject.org/blog/?p=340#comment-670 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. 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.

]]> By: guenter http://pocoproject.org/blog/?p=340&cpage=1#comment-662 guenter Fri, 19 Feb 2010 09:09:58 +0000 http://pocoproject.org/blog/?p=340#comment-662 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. 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.

]]> By: Aurelien Derouineau http://pocoproject.org/blog/?p=340&cpage=1#comment-660 Aurelien Derouineau Thu, 18 Feb 2010 00:19:49 +0000 http://pocoproject.org/blog/?p=340#comment-660 guenter, I suppose, from what you've been saying, that you're already set on git and do not wish to consider hg (mercurial)... guenter,

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

]]> By: guenter http://pocoproject.org/blog/?p=340&cpage=1#comment-657 guenter Wed, 17 Feb 2010 17:37:51 +0000 http://pocoproject.org/blog/?p=340#comment-657 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. 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.

]]> By: Brian Holdsworth http://pocoproject.org/blog/?p=340&cpage=1#comment-656 Brian Holdsworth Wed, 17 Feb 2010 17:29:26 +0000 http://pocoproject.org/blog/?p=340#comment-656 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. 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.

]]> By: Brad Phelan http://pocoproject.org/blog/?p=340&cpage=1#comment-653 Brad Phelan Tue, 16 Feb 2010 14:31:06 +0000 http://pocoproject.org/blog/?p=340#comment-653 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 :) 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 :)

]]> By: Aurelien Derouineau http://pocoproject.org/blog/?p=340&cpage=1#comment-652 Aurelien Derouineau Tue, 16 Feb 2010 09:18:07 +0000 http://pocoproject.org/blog/?p=340#comment-652 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) 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)

]]> By: Franky Braem http://pocoproject.org/blog/?p=340&cpage=1#comment-651 Franky Braem Mon, 15 Feb 2010 06:38:48 +0000 http://pocoproject.org/blog/?p=340#comment-651 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. 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.

]]> By: Devin Akin http://pocoproject.org/blog/?p=340&cpage=1#comment-646 Devin Akin Thu, 11 Feb 2010 10:35:07 +0000 http://pocoproject.org/blog/?p=340#comment-646 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. 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.

]]>