git svn fetch retrieves the same Subversion revision multiple times for branches

Question

I am seeing git svn fetch repeatedly retrieve the same Subversion revisions when it finds branches in my 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 something like this:

r2537 = d5b22e956157af036d4112e42e8fb927e45758c8 (trunk)
        M       Enterprise/VC/libgc/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?

Answer 1

I noticed this question because I got the same error message:

W: Refspec glob conflict (ref: refs/remotes/trunk):
expected path: branches/trunk
    real path: trunk

It turned out that .git/config had duplicate lines that seem to confuse git-svn, like this:

[svn-remote "svn"]
...
    branches = project/branches/*:refs/remotes/*
    tags = project/tags/*:refs/remotes/tags/*
    branches = project/branches/*:refs/remotes/*
    tags = project/tags/*:refs/remotes/tags/*

Removing those duplicates solved weird git-svn behaviour for me, and might as well for you. I'm not sure what caused git-svn to duplicate this information in the first place. I killed and continued the initial clone, this might be related?

Answer 2

Removing duplicates still created an issue for me. Each time you rerun your clone command e.g. git svn clone svn://.../svnroot --no-metadata -A authors-transform.txt --stdlayout . It adds two more lines to .git/config. I had to remove all lines containing branches = branches/:refs/remotes/ and tags = tags/:refs/remotes/tags/

Leaving config looking like below:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[svn-remote "svn"]
        noMetadata = 1
        url = svn://.../svnroot
        fetch = trunk:refs/remotes/trunk
[svn]
        authorsfile = /home/users/denn/authors-transform.txt
~

Answer 3

If, at any point, the trunk of your repository existed at a different location in SVN, try specifying this location to additionally fetch in the repository's config file. For example:

[svn-remote "svn"]
... 
    fetch = project/trunk:refs/remotes/origin/trunk
    fetch = previous/location/of/trunk:refs/remotes/origin/trunk-old1
    fetch = another/location/of/trunk:refs/remotes/origin/trunk-old2
    ...

For the project I was importing, there were many branches and tags that had been created from these previous locations. Since these were branches/tags created from an 'unknown' place, git svn was throwing up its hands and just fetching all the history to find out. (This approach still required a full fetch for each location, but that was MUCH faster than a full history fetch for every tag)