Re: [PATCH] Teach git-svn how to catch up with its tracking branches

[Chris Shoemaker <c.shoemaker@cox.net>]

On Wed, May 07, 2008 at 11:48:17PM -0700, Asheesh Laroia wrote:
> On Wed, 7 May 2008, Steven Grimm wrote:
>
>> In environments where a lot of people are sharing an svn repository using
>> git-svn, everyone has identical, but individually maintained, tracking
>> branches.
>
> To further muddy the waters, let me talk about my setup, also one with a 
> "central git repository" from which all developers clone, and also one 
> based on a Subversion tree.
>
> The way I handle it is that, hidden somewhere, I have an account with a 
> cron job that does this:
>
> $ git svn fetch
> $ git push origin refs/remotes/*:refs/heads/*
> $ git push origin refs/remotes/trunk:refs/heads/master
>
> The first push synchronizes "origin" to have the same branches as this 
> git-svn copy of the git repository, and the second updates "origin" so that 
> it has a "master"; without that second step, "git clone" will error out 
> when it get to its checkout phase.

This got me thinking about a potential design for a git-svnserver.
[Warning: engineering hack ahead, proceeed with caution.]

Instead of re-implementing any part of svn, just use a stock svn repo
+ server.  From the svn post-commit hook, update a git-svn repo as
above.  From the git post-commit, do a git-svn rebase.  Of course, you
need a shared lock between the two pairs of pre/post commit hooks.

The problem of attribution in svn from git-svn is probably easier to
solve from within the context of a post-commit hook.  The problem of
having to round-trip git commits through svn in a way that changes
their ids remains.  Effectively, that means commits have to be
considered "unpublished" (for the purpose of not basing other work
upon them) until they are pushed to the git-half of the git+svn.

Still, this scenario is a pretty gentle migration path from svn to git
- one that allows regular git users to use only git-core, not git-svn,
and still allows svn clients to work.  Maybe some git-alias magic
could hide the fact that a git push has to really become a push +
fetch.


-chris