On 25-11-12 12:28, John Ralls wrote:
On Nov 25, 2012, at 8:00 PM, Geert Janssens <[email protected]> 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
So you basically propose to get jeeves out the the equation first and
only then go into the website migration. That's fine with me as well.
Since gitolite will be installed on the same server that hosts the svn
repos (code.gnucash.org, located at Derek's), keeping svn and git in
sync should be easier there anyway. There's no need to include a port
knock to update the local gitolite repos. The svn post-commit hook can
do that straight away.
So first steps:
1. create a gitolite repo for all 4 svn repos we currently have:
gnucash, gnucash-docs, htdocs and meta. Initially they should still have
the svn repos as upstreams.
2. set up triggers in the svn repos that will initiate a git pull in the
relevant gitolite git repos, to keep svn and git fully in sync
3. install triggers in gitolite to push changes to github. This trigger
can be based on the script already used by John on jeeves. It can
probably be simplified a bit, because there's no need to run an svn
update (or git update) before pushing the commits to github. The svn
post-commit hook did this already.
Drop the jeeves synching at this point.
4. continue step 3 from the original proposal. Step 6 can be skipped,
because that's already done.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
