Issue running git-svn-mirror script on code
jralls at ceridwen.us
Sat Jan 26 11:30:42 EST 2013
On Jan 26, 2013, at 2:04 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> On 25-01-13 20:19, John Ralls wrote:
>> On Jan 25, 2013, at 9:43 AM, Geert Janssens <janssens-geert at telenet.be> 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 do have a G+ account, but I don't know how to put something on the Gnucash stream. I can put it on my own stream, but that won't do a lot of good.
>> 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
Yes, the intermediate repo is a working repo while the gitolite one is a bare repo. AFAIK git-svn can't work directly with a bare repo, so it has to be that way.
>> Is that what's in place now (except to a stand-in repo on code.gnucash.org 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