On Nov 27, 2012, at 4:03 AM, Derek Atkins <[email protected]> wrote: > 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.
OK. Sounds like you've got the next action item, get the email hook set up. After that, you can install git-svn-mirror from Github and work out how to trigger it from svn. I think you can clone the Github repos to save some time (it takes several hours to make a fresh git-svn clone of an svn repo), then use git-svn-mirror to update it directly from svn. A bare git repo is one that has no working files and puts all of the git state files in the main directory instead of in a .git directory. You can't commit to it, or checkout branches, but you can do just about anything else, including pushing to another repo. I highly recommend Pro Git [1] to help you go from git rookie to expert. It's free online or you can buy a dead-trees copy for bedtime reading. Regards, John Ralls [1] http://git-scm.com/book _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
