Subject: Re: Automating svn<->git gateway

From: Jakub Narebski <[email-masked]>
Date: Fri, 15 Oct 2010 18:48:59 +0200

On Wed, 13 Oct 2010, Jan Hudec wrote:
> On Wed, Oct 13, 2010 at 01:25:48 +0200, Jakub Narebski wrote:
> > On wtorek 12. października 2010 22:31, Jan Hudec napisał:

> > > So while I'm sure the native SVN support will solve the quirks and bugs of
> > > git-svn, it will not do away with need for the gateway repository that will
> > > somehow synchronize itself with subversion.
> > 
> > Well, I think that native SVN support would allow to treat subversion
> > repository as one of repositories in the network of repositories.  Those
> > repositories could be set in that pushing to central git repository pushes
> > also to subversion repository, and like central git repository fetches
> > from leaf repositories, it would fetch from subversion repository.
> 
> Yes. Except I don't know how to do the "pushing to central git repository
> pushes also to..." part. Subversion or not.
> 
> Though, I guess if it worked well enough to preserve the merge commit (i.e.
> when I push and pull, I see the commit I pushed, not any kind of rewrite),
> pushing in update-hook would be quite many bits simpler.

I was thinking about setting up appropriate hook for that...

...but it might have been also done "manually", i.e. by having maintainer[*]
do something like 'git pushall' to push to all distribution points (public
git repositories), including Subversion repository, when pushing from 
his/her private repository to public repository/repositories.  Maintainer
would fetch (pull) from all leaf repositories, including Subversion
repository.  This means that SVN repository is both leaf and distribution
point.

[*] I wonder if "The surgical team" idea (less known than "The mythical
    man-month" aka 'assigning more programmers to a project running behind
    schedule will make it even later') from seminal work by Fred Brooks'
    "The Mythical Man-Month" is still valid.  The 'surgeon' would be the
    maintainer / code reviewer, and would be responsible for merging in
    code from other developers.

-- 
Jakub Narebski
Poland