git svn fetches the same revision multiple times for non-trunk branches

I am seeing git svn fetch repeatedly retrieve the same Subversion revisions when it finds branches in our Subversion repository. We are using the standard Subversion repository layout, with top level / trunk, /tags, and /branches directories (and the git repository was created with 'git svn init -s'). However, the problematic branches are often copies made from a subdirectory inside of trunk, instead of trunk.

The git svn fetch output typically looks like:

R2537 = d5b22e956157af036d4112e42e8fb927e45758c8 (trunk)
         M       Enterprise/VC/lib/SymbolVenue.cpp
r2538 = cfed4ca0491da0b732f32bfff72ba678450a0915 (trunk)
Found possible branch point: http://repo/prod_repos/trunk/Enterprise/ 
VC => http://repo/prod_repos/branches/file_conversion, 2523
W: Refspec glob conflict (ref: refs/remotes/scripter@832):
expected path: branches/scripter@832
     real path: trunk/Enterprise/Python
Continuing ahead with trunk/Enterprise/Python
W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: branches/trunk
     real path: trunk
Continuing ahead with trunk
Initializing parent: file_conversion@2523
         A       gc/QuoteService.cpp
         A       gc/TestSuite.h
         A       gc/quote_svc.pro
         A       gc/QuoteService.h
.....

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)
         D       gc/FixMessageLogger.h
.....
r5 =
r19 =
r20 =
.....

And we are back at revision 1. git svn fetch then continues to fetch revisions until it reaches the revision that created the branch.

What am I doing wrong? Is there anyway for me to tell git svn fetch to not retrieve revisions it has already pulled? This is converting my import time from O(n) to O(n^2).

Robert

Robert Zeh <robert.a.zeh@gmail.com> wrote:

Hi Robert,

Yes, this is a known problem with some repositories and there's no automatic/easy[1] way to handle it with globbing tags/* or branches/*.

You can try to track each tagged project independently or to setup individual fetche lines (like the one generated for trunk). in .git/config for each tag/branch.

[1] - Unfortunately SVN allows way too much freedom and thus ambiguity in how it treats tags/branches and that doesn't allow mapping those things to git very easily.

So is the basic problem that the history of the branch is unknown and we have to retrieve the history?

Robert On Jul 25, 2009, at 5:51 AM, Eric Wong wrote:

Robert Zeh <robert.a.zeh@gmail.com> wrote:

Yes, or rather it's not known that it's a branch/tag:

Say you have something like this:

  /trunk/client
  /trunk/server
  /trunk/design_docs_specs_and_whatnot
  /tags/client_1.0
  /tags/client_1.1
  /tags/server_1.0
  /tags/server_1.1

But you're tracking /trunk, /tags/*, /branches/* like you normally do, all the developers usually work off /trunk anyways because /client changes are tied to /server and they have both checked out and they also need to read/update the docs common to the server and client.

However, tags are deployed to separate machines and the docs don't need to be; so they're tagged separately off their respective working directories.

So when git svn sees /tags/client_1.0, it'll think that it was tagged off /trunk and not /trunk/client. But since you're tracking /trunk and not /trunk/client, it can't find history in /trunk. So it starts tracking /trunk/client anew without taking /trunk into account.

So git svn will create a ref that looks like tags/client_1.0@REV. What git svn could (and if somebody found time to work on it) is to reuse any/first tags/client_1.0@REV tags it finds.

And simply using the existing git history of /trunk to see the history of /trunk/client is suboptimal, too, because /trunk/client could've originally come from /client (an actual case I've encountered) before /trunk existed.

Remember, unlike SVN, git doesn't track directory renames (or renames, or directories at all) for that matter. This is a huge fundamental difference between the two systems and mapping between them was one of the greatest difficulties I had with git svn.

The very first version of git svn was something that would only ever dumbly track one directory (and it still supports that mode of operation, just don't pass any options to init/clone). So a git working tree might have trunk, branches/*, tags/* all on the filesystem. It's a very big working tree in some cases, but it was the easiest to implement because it didn't do anything smart.