Git Migration: github with svn access

[John Ralls]

On Nov 7, 2011, at 11:07 AM, Geert Janssens wrote:

> On maandag 7 november 2011, Christian Stimming wrote:
>> Zitat von Derek Atkins <derek at ihtfp.com>:
>>>>> We've been using the Github repos pretty successfully for 8 months or
>>>>> so now. I think all of the main committers this year (meaning more
>>>>> than a commit or so per month ) are using it. Meanwhile, Derek has
>>>>> upgraded the servers and moved them to a new location, so there should
>>>>> be no technical barrier to switching to git for the main repository.
>>>> 
>>>> I'd love to see git to be the main repository.
>>>> 
>>>> Would that mean we drop the svn repo ? The windows automatic build
>>>> scripts still depend on svn and won't work with git.
>>> 
>>> Right now the web site update, docs nightly build script, doxygen nightly
>>> build script, and win32 nightly build script all depend on SVN.  All this
>>> infrastructure would need to migrate over to git.
>>> 
>>> Would we continue to host the main git repo on Github?  Or would we keep
>>> the main repo on code.gnucash.org?  If the latter, we would need to
>>> figure out how to authorize pushing as well.
>> 
>> My suggestion is to move the main git repo also to a github one, and
>> not maintaining our own source code server. My reasons for this is an
>> easier administration of adding main commit access, and also a much
>> easier handing over of the administration priviledges itself - which
>> is currently "hard coded" to Derek as the root account owner on the
>> gnucash box.
>> 
> Ok by me.
> 
>> If we decided to move not only to git, but also to github, we'd solve
>> most of the build script integration issues: github offers the
>> additional feature of accessing its git repos also by a svn client, see
>>   https://github.com/blog/966-improved-subversion-client-support
>> 
> Very interesting. I wasn't aware of this.
> 
>> I think only the website set-up needs some more work. All other
>> integration only depends on the availability of a svn checkout, which
>> would already be there on github.
>> 
> The website and the mails that get automatically sent to gnucash-patches and 
> gnucash-changes.
> 
> The mails may not be an issue. Instead of a mailing list, github provides an 
> rss feed (on your personal account, based on all the projects you have marked 
> for watching). That may be sufficient.
> 
> If not, I found that git does provide service hooks upon push, but I'm not 
> quite sure which ones could implement what we need:
> https://github.com/Gnucash/gnucash/admin/hooks (url only accessible by gnucash 
> admins on github)
> - The e-mail hook may work as an alternative to the two commit mails we send 
> now, although there's not much we can configure.
> - The Post-receiveURL hook could possibly be used for the website update 
> parts. We would have to provide a post listener somewhere though that can 
> trigger the proper actions. While we are setting up such a service, it could 
> just as well also be used to send the e-mails instead of the more limited e-
> mail hook above.
> 
> Other hooks that could potentially be useful, though not required for the 
> migration:
> - Bugzilla hook, which automatically adds comments to bugs if a bug number 
> appears in the commit message.
> - Trac, interfaces with a trac installation (which we also still have)

We can try setting up the hooks now. The events that Github sees are the same as they will be later, it's just that there will be more pushers.

I don't know if we necessarily want to automatically add comments to bugs. What would be nice is for the bug reference getting turned into a link when browsing on Github so that you could just click on it and be taken to bugzilla.

I don't see any need for Trac after migration. We're only using it for browsing the repo.

I actually like the interface on git.gnome.org better than github's (or trac's). Less froo-froo, and the history is a lot more readable and searchable. OTOH, I do like the line-by-line comment feature on Github. (I'm not suggesting we should try to move to git.gnome.org. Getting everyone access would be a big PITA. But we could host whatever they're using for a browser on code.gnucash.org.)

Regards,
John Ralls