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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
