From: Chris Shoemaker <c.shoemaker@cox.net>
Date: Thu, 08 May 2008 01:58:06 GMT
Subject: Re: [PATCH] Teach git-svn how to catch up with its tracking branches
Message-ID: <20080508015806.GA759@pe.Belkin>
In-Reply-To: <20080508013956.GA24956@midwinter.com>

On Wed, May 07, 2008 at 06:39:56PM -0700, 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. If the svn repository is very active, it can take a while to
> run "git svn fetch" (which has to individually construct each revision
> by querying the svn server). It's much faster to run "git fetch" against
> another git-svn repository to grab the exact same git revisions you'd get
> from "git svn fetch". But until now, git-svn was confused by this because
> it didn't know how to incrementally rebuild its map of revision IDs.
> The only choice was to completely remove the map file and rebuild it
> from scratch, possibly a lengthy operation when there's a lot of history.
> 
> With this change, git-svn will try to do an incremental update of its
> revision map if it sees that its tracking branch has svn revisions that
> aren't in the map yet.

Since I'm not qualified to review the patch technically , I'll just
offer encouragement, comment and question.  First, nice work, this
seems like a very helpful feature.  It might go quite a way toward
enabling a semi-distributed workflow with an authoritative svn
upstream.

Second, what will happen when different developers have svn URLs with
different schemes, e.g. http vs. svn+ssh?

Third, I think such a feature surely deserves a mention in
git-svn.txt.

-chris