Git Migration

From GnuCash
Jump to: navigation, search

GnuCash has been 2012/13 in the process of migrating from svn to git. Many parts of the GnuCash development process relied on svn before. All these parts have been rewritten to work with either svn or git(hub).

This page intended to keep track of the parts that had to be reworked.

List of things to be done

Area Files Description Status
Win32 build packaging/win32/ The equivalent of svn update should be implemented. Our custom git-update script could be good to start with, but is currently not part of the GnuCash git repository, so it has to be fetched from somewhere else. DONE 2012-08-12
Win32 nightly build packaging/win32/

packaging/win32/ packaging/win32/ packaging/win32/

Each of these files uses svn for either update, get tags, get revision and so on. An equivalent in git should be setup. Personally, I think the cleanest would be to create a second set of scripts for git, which is a copy of the original scripts with all svn usage replaced with git usage. These scripts can then be called to daily_build.bat independently from the svn ones.

Additional tricky part: git can't be in the PATH, because its dll's conflict with the GnuCash ones.

DONE 2012-08-12, and activated in daily_build.bat as of 2013-06-16 (for 2.5 and up)
Docs nigthly build  ? There is a script that build and uploads the documentation every night. I don't know where this script is stored. DONE late 2013
Doxygen nightly build  ? Equally there is a script that builds and uploads the doxygen documentation every night. I don't know where that script is stored. DONE late 2013
Commit hooks  ? Currently when a patch is committed, notification mails are sent out. We should figure out how to set this up on github. 2013-01-30 Mostly done. We have set up gitolite on Gitolite already has a mechanism for access control, and I have added a script that sends out notification mails. TBD: the mails seem to have some UTF-8/locale issues.
Website update  ? Another commit hook will update the website whenever changes are committed to the htdocs svn repository. If the repository migrated to github as well, we'll have to figure out how to trigger these updates from within github. DONE The website is now updated from git instead of svn.
Win32 build - Git has to be configured for consistent end of line handling across platforms. Currently, commits checked in on a linux box cause all kinds of issues on Windows due to its different handling of end of lines. For example, a git pull will fail with "white space errors" due to this. This has mostly been dealt with by introducing a .gitattributes file in the repository. For older version of git, users should set the eol style in their repo or global preferences. Christian's message on the gnucash-devel mailinglist has some more details regarding this.
Changelog creation The toplevel makefile has some rules to automatically generate a Changelog file based on the revision history extracted from svn. If we switch to git, this has to be rewritten to work from the git repo. 2013-05-17 DONE The makefile now determine what type the repository is and will generate the ChangeLog from either svn log or git log.
List of changes for news files util/svnlog2ul This is a small script that extracts the changes from svn history between to revisions and parses it into a nice html formatted unordered list. This can then be used to easily generate the news items for the website. A similar tool should be written to extract this info from git. 2013-05-17 DONE. util/ does the same thing based on git log.

Github or self-hosting at ?

The discussion on this has been ongoing for a long time. The section below will try to list as many advantages and disadvantages of both options as possible to make it easier to decide.

Pro Con
  • Good uptime
  • Easily caters for multiple admins
  • High visibility
  • Makes cloning very easy
  • Very popular
  • Continued (limited) svn access via a git-to-svn bridge for those who prefer to stick with svn
  • Reduces bandwith usage on the
  • Not under our own control
  • Built-in pull requests and bugtracking have their issues (according to John). We don't have to use those, but likely people will, since we can't disable them (or can we ?).
  • Under our own control
  • Single point of failure (one internet connection, one single admin)

Still to be investigated in May 2013, but done in between

  • Integration with our existing infrastructure like commit hooks and htdocs, ...