Issue running git-svn-mirror script on code

Geert Janssens janssens-geert at
Sat Jan 26 05:04:18 EST 2013

On 25-01-13 20:19, John Ralls wrote:
> On Jan 25, 2013, at 9:43 AM, Geert Janssens <janssens-geert at> wrote:
>> On 25-01-13 18:12, Derek Atkins wrote:
>>> I'm fine with this.  I *may* have some time this weekend, but not a
>>> lot.  I promised I'd use this weekend to clean up my office so I wont
>>> really be online much.
>> I won't have time this weekend.
> I don't think we want to do this over this weekend. I'll write the news article and contact the github fork owners today. I don't know how to (or who would) propagate the news article onto the social networks.  Just for redundancy I'll copy it onto the mailing lists as well.
It looks like someone already has taken care of putting it on facebook 
(I'd guess Cristian did this). I don't have a google+ account. I've 
added a note on the LinkedIn gnucash page referring to the news item on 
our main site, though it's under moderation currently.
> ...
> I guess the best way would be svn->gitolite->github, so when we drop svn and start committing to gitolite directly we don't have to do anything.
That is how it is planned indeed. For completeness, I'll just point out 
that the push to github (or any other stand-in repo) is missing still 
and there's an additional intermediary repo involved for the svn->git 
sync. So currently we have this:
svn -> intermed repo -> gitolite

>   Is that what's in place now (except to a stand-in repo on instead of github)?
There is no stand-in repo. The current end point is gitolite.

I never imagined a stand-in repo. In retrospect I understand now it can 
be useful to test our commit hook. We can set up a hook in gitolite and 
let it push to a temporary (local) repo, just to make sure the hook 
works. Once it works, we only have to change the origin config parameter 
in the gitolite repos to point at github instead of the stand-in and 
we're done. Is that what you had in mind as well ?
>>> 2) writing the gitolite hook script(s) to push the updates up.  Again, I
>>> want to make sure it's done right.
>> We could write pure git hook scripts and insert them in each repo, but I think it would be more useful to manage all the hook scripts inside the gitolite-admin repo. This will allow each admin to make the necessary updates.
>> In order to do so, you will have to configure gitolite to look for hooks in the gitolite-admin repo. Here's a starting point:
>> Basically, you set LOCAL_CODE to some location inside the gitolite-admin repo and create the directory structure as shown in the second link. Then we can add hooks in hooks/common. From what I understand, gitolite hooks are just like git hooks, with the exception that the "update" hook is reserved for gitolite.
>> So we need to figure out what is the equivalent git hook to svn's post-commit, and write a script that does what we want: send mails upon commit. From
>> I find a post-commit hook that can be used or the server side's post-receive. The former is closer to the svn's post-commit, so is probably the easiest to work from.
> These other hooks need to happen sometime before we drop svn, but that's not going to be for a while, so there's plenty of time to work on it... though once the website hook is in place we surely could drop svn for docs and htdocs, since there's no 2.4 tail holding us back.
That's true for htdocs, but not for docs. The windows build server 
depends on the docs svn repo to build the 2.4 series and tags. We'll 
have to keep gnucash and gnucash-docs available in svn until either we 
drop support for 2.4 or update the build scripts to work with git for 
both 2.4 and new tag builds.
>>> Once we do this then we should make sure that the only account that can
>>> write into the github repos is the code-gnucash-org account that I set
>>> up specifically for the server automation.
>> Except for some admins maybe, just in case something goes out of sync and some manual intervention is needed. Anyway, modifying these write permissions is straightforward on github.
> Which, AFAICT is how it's set up right now.
Indeed. I meant to imply to keep it that way.


More information about the gnucash-devel mailing list