Hi, John Ralls <[email protected]> writes:
> On Nov 25, 2012, at 8:51 PM, Geert Janssens <[email protected]> wrote: > >> 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. > > > There are only 3 SVN repos. The fourth repo on github (git-helper-scripts) > has the svn-git interface scripts. One of these, git-svn-mirror, is the > important jeeves script to get working with gitolite. The gitolite repos can > be created with this script as well or they can be cloned from jeeves (which > will take considerably less time). I haven't looked at the gitolite docs yet, > so I won't comment further. > > Step 3 is trivial. The trigger just calls `git push`. I have gitolite set up on code.gnucash.org. Basically it's a "git management solution" that lets us remotely manage a set of git repos. I've added all the current account holders, so everyone who can currently access code has a "gitolite" account. Currently only Geert and I have access to the admin section. Gitolite effectively provides a "bare git repo" to each repository it manages. I can then run system-wide or per-repo hooks to e.g. mail out commit messages or push to github. We haven't set up any hooks, yet. I'd like to at least get the email hook set up before we do anything else. We then have to figure out how to best set up a "git push --all" to push to github, especially when the bare repo isn't a clone itself. This is where my knowledge of git falls short so I'm definitely going to need help here. My recommendation is that we first work on migrating the gnucash repo. Then we can work on the gnucash-docs and htdocs repos. So worrying about the website is, IMHO, premature at this stage. > Regards, > John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [email protected] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
