Migrating gnucash website from svn to git

[Geert Janssens]

This morning I have been thinking out loud on irc on the best way to 
migrate our website infrastructure from svn to github. This is part of 
the overall effort to move all GnuCash svn dependent activities to git.

Short background on our website's relation to svn
- The website is maintained in an svn repository called htdocs (hosted 
on code.gnucash.org)
- The website itself is run on an external server, maintained by Linas.
- On the webserver, the website is stored as a checked out subversion 
working directory
- Whenever someone commits a change to our htdocs svn repository, the 
webserver is triggered to update the svn working directory, which keeps 
it in sync with the svn repo at all times.
- Besides all of this, we also have set up a htdocs git repository on 
github. This repo is read-only.
- Each update to the svn repository trigger an additional script that 
pushes all changes from the svn repo to github, to keep both in sync at 
all times as well.

This should be transformed into:
- The website is maintained in a gitolite git repository called htdocs 
(still on code.gnucash.org)
- The website itself is run on an external server, maintained by Linas.
- On the webserver, the website is stored as a git repository cloned 
from the gitolite repo
- Whenever someone commits a change to our gitolite htdocs repo, the 
webserver is triggered to pull that comit into the cloned repo, which 
keeps both repos (or more precise: the checked out branch)  in sync at 
all times.
- Besides all of this, we also have set up a htdocs git repository on 
github. This repo is read-only.
- Each update to the gitolite repo will trigger an additional script 
that pushes all changes from the gitolite repo to github, to keep both 
in sync at all times as well.

Sidenote for those who haven't been following the git migration 
conversations closely: gitolite is a companion to git which allows 
multiple admins to manage access rights to multiple git repositories on 
a given host.
The git repositories that will appear on code.gnucash.org will be 
considered the master git repos. Only the currently active developers 
with commit access to svn will also have commit access to the gitolite 
managed git repos. All others will have read access only, just like on 
github.

Doing the htdocs migration in one go doesn't seem like a good idea to 
me. There are too many potential stumbling blocks in the whole migration 
that it would be very hard to debug if everything was changed at once. 
So I have come up with the following steps to break it all down in easy 
to debug small changes:

1. setup a htdocs repo it gitolite, initially with the svn htdocs as 
upstream repo
That allows us to test gitolite and overcome any initial hurdles there

2. setup a trigger in the svn htdocs repo that causes a git pull in the 
htdocs git repo each time svn htdocs is changed
That will keep htdocs in sync with svn at all times and keep it ready to 
take over master status at any time

3. configure a git htdocs post-commit hook to update the live website 
and disable the same commit hook in svn. The net effect should be that 
anything committed to svn will automatically be pushed through to 
gitolite, which in turn will trigger the website update from now on. 
Note that the websites themselves are still svn based, to the trigger 
action is still an svn update in this step.

4. If all that works well, we can go one step further: replace the beta 
site with a git repo on the webserver and write an trigger script that 
issues a git pull instead of an svn update
This should get triggered together with the svn update trigger script 
for the main website and allows us to tune the needed git changes on the 
webserver

5. If it works for beta, we can do the same for the main website

6. In parallel to much of this, the trigger that is currently run by 
John to update github can now be installed on the htdocs git repo on 
code.gnucash.org, that is, for htdocs only. Obviously the other repos 
are still svn based at this point.

7. if all the above is working svn htdocs should be disabled, and htdocs 
on gitolite declared master
This could be done by
- disabling all write access to svn htdocs,
- removing the svn repo as upstream from htdocs git
- and asking anyone to use htdocs git from now on (either checked out 
from github or from code)

I think such a step by step proces will allow us to debug each small 
step in turn.

Comments/feedback ?

Geert