Migrating gnucash website from svn to git

[Derek Atkins]

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?

> Geert

-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
       warlord at MIT.EDU                        PGP key available