git svn fetch retrieves the same Subversion revisi

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

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)

Answer 2

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 3

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 4

git-svn appears to be repeatedly pulling the same revisions because you have tags in your SVN repository. SVN's concept of a tag is slightly different from git's: SVN tags are actually branches (thus SVN tags are copies).

Take a closer look at your output:

r1 = d349ed8cb2d76596fe2b83224986275be4600fad (QuoteSvcFix442@2698)

Although the revision r1 = looks too familiar, the rest of the text probably differs. At a minimum, the tag name (in this case QuoteSvcFix442@2698) will not be the same.

I think the only way to prevent this is by having git-svn skip the SVN tags. If you can't live without the tags, you can also convert the SVN 'tag' branches to real git tags (but you have to fetch all the tag branches, first!)

---

A related SO question with possible work-arounds: Can Git-svn be used on large, branched repositories?

Some discussion about this issue: git-svn --tags should at least /try/ to handle tags as tags.