Migrating gnucash website from svn to git

[John Ralls]

On Nov 28, 2012, at 6:10 AM, Derek Atkins <warlord at mit.edu> wrote:

> Geert Janssens <janssens-geert at telenet.be> writes:
> 
>> On 27-11-12 15:06, Derek Atkins wrote:
>>> John Ralls <jralls at ceridwen.us> writes:
>>> 
>>>> 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.
>>> Do we really want to continue using SVN once we migrate to git?
>>> Note that I'm talking about the gnucash repo, not htdocs here.
>> I think we should keep svn as canonical repo until we decide to drop
>> support for 2.4. I think that none of my git-migration related work is
>> backported. And even if that could be backported easily (I'd have to
>> verify but I'm short in time right now) I wouldn't change the
>> canonical repo until we are sure everything works as we want it. All
>> that time, svn should be the main repo IMO and gitolite should
>> consider the svn repo as upstream.
>> 
>> In git it's rather easy to decide later on to drop this upstream link.
> 
> Ah, true, didn't really think about 2.4.  Yes, of course, we need to
> keep SVN around for 2.4 support.  What it means is that we're still
> using SVN for commits; I don't think we can push to gitolite and have it
> push to SVN and github, so we're still stuck with pushing to SVN and
> then pulling into git until we give up on SVN completely.
> 
>>>> 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.
>>> Fair enough.  I'm just not sure how you specify where to push/pull from
>>> if it's not a clone, i.e., if it's just been pushed to from somewhere
>>> else.
>> 
>> I don't understand what you mean here.
> 
> John did and answered my question.
> 
>> Assuming the setup where svn is canonical, gitolite is configured with
>> svn as upstream and github is considered a downstream from gitolite we
>> get:
>> - a dev commits something to svn
>> - the svn post-commit hook runs a git command that causes gitolite to
>> read in the new svn commits. I imagine some variant of our git-update
>> script will be needed here (one that doesn't attempt to fast-forward
>> checked-out branches)
>> - the updates in gitolite will eventually trigger gits post-received
>> hook in which we push the changes through to github using git push
>> --all. Here is also were the commit mails can be sent.
> 
> Yeah, I suspect we'll need an intermediary checkout to make this work
> right.  At least, I don't know if one can setup an svn 'git remote' in
> an existing bare repository?
> 
>> Once svn will be dropped, devs will push commits directly to gitolite,
>> which will trigger the same git post-received hook to push to github
>> and to send mails.
> 
> Right.
> 
>> Which part is not clear for you ?
> 
> At the time it was how to set up a bare repository to add the github
> remote in order to push to it.  John cleared that up.  Now the only
> question is whether I can add a git-svn remote to an existing bare repo
> or if I need to have an intermediary repo somewhere else?

AFAICT git-svn doesn't work on a bare repo. You'll have to clone the Github repos and run git-svn-mirror on those clones after adjusting the config file to look like the one in the wiki page [1]. Set the "origin" remote to point to the gitolite bare repo.

Gitolite provides a mirroring facility [2] that will automatically send changesets on to Github.

Regards,
John Ralls

[1] http://wiki.gnucash.org/wiki/Git#Setting_up_and_Maintaining_the_Mirror
[2] http://sitaramc.github.com/gitolite/mirroring.html