From: Jakub Narebski <jnareb@gmail.com>
To: Jan Hudec <bulb@ucw.cz>
Cc: git@vger.kernel.org
Subject: Re: Automating svn<->git gateway
Date: Fri, 15 Oct 2010 18:48:59 +0200 [thread overview]
Message-ID: <201010151849.00161.jnareb@gmail.com> (raw)
In-Reply-To: <20101013171734.GA3693@efreet.light.src>
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
prev parent reply other threads:[~2010-10-15 16:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-11 19:30 Automating svn<->git gateway Jan Hudec
2010-10-11 20:33 ` Joshua Shrader
2010-10-12 17:35 ` Jan Hudec
2010-10-12 19:54 ` Jakub Narebski
2010-10-12 20:31 ` Jan Hudec
2010-10-12 23:25 ` Jakub Narebski
2010-10-13 17:17 ` Jan Hudec
2010-10-15 16:48 ` Jakub Narebski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201010151849.00161.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=bulb@ucw.cz \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).