Migrating gnucash website from svn to git

[John Ralls]

On Nov 25, 2012, at 8:00 PM, Geert Janssens <janssens-geert at telenet.be> wrote:

> 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 ?

The svn-side hook is a simple tcp knocker that fires off a script on my server. It should be trivial to duplicate that to Linas;s servers.

It doesn't make sense to me to have a git-svn replica on both code and jeeves (my server). Let's :
1. Get gitolite set up and work out how to get it to push to github. Once that's working for all three repos,

2.  we can stop running through jeeves and proceed to getting the post-commit-hook working with a test website on Linas's webserver. 

3. Implement the post-commit-hook with the live web pages

4. Turn off svn.

Regards,
John Ralls