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 reposit

Answer 1

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.

Answer 2

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 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

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?