git-svn “Couldn't find revmap”- what does it mean?

Question

When running git svn clone and often during subsequent git svn fetch operations I get this message for a number of folders:

Couldn\'t f         


        

Answer 1

Just wanted to note - there is actually a hidden file in git-svn, called something like

.git/svn/refs/remotes/git-svn/.rev_map.00088888-caaa-4444-9999-2222eeeeeee4

... where the closing id is the Repository UUID or git-svn-id.

This is a binary file, and there is a bit more on it in /usr/lib/git-core/git-svn:

# rev_map: ...
# This is the replacement for the rev_db format, which was too big
# and inefficient for large repositories with a lot of sparse history
# (mainly tags)
#
# The format is this:
#   - 24 bytes for every record,
#     * 4 bytes for the integer representing an SVN revision number
#     * 20 bytes representing the sha1 of a git commit
...
#   - Piping the file to xxd -c24 is a good way of dumping it for
#     viewing or editing (piped back through xxd -r), should the need
#     ever arise.

Note that output looks something like this:

$ cat .git/svn/refs/remotes/git-svn/.rev_map.*  | xxd -c24 | head -1
0000000: 0000 0001 33ee 22cc 9933 88aa 44ff 22dd 5566 88ee 66aa bbcc  ....5.'..?..J...Zj..`...

I think that when you type git svn info, it is this file which is consulted, so that you get an SVN revision number based on the git SHA hash for a commit. I have no idea how one could reconstruct it, though (althogh git svn reset may help erasing entries from this file, not 100% sure not this)

Answer 2

I don't have the complete answer, but this error is generated by git-svn.perl. (The relevant code path seems to be do_fetch -> make_log_entry -> find_extra_svn_parents -> lookup_svn_merge.) That code appears to be trying to look at a svn merge commit's svn:mergeinfo property to figure out all its parent commits/branches, in hopes of turning that into a nice, multi-parent merge commit inside the git clone. If that parent resolution fails, your commit will still get fetched into git; it just won't have the same parent info as it would otherwise.

So far, I haven't personally found any big problems stemming from this error for my current main use case, which is converting a svn repo to git; git-svn has been able to resolve the big merges that actually matter to me, and these errors so far seem limited to either individual cherry-pick merges or old branches that I don't care about anymore.

Actually, on second glance, it looks like in my case most of these errors stem from commits where svn:mergeinfo got recorded at what I interpret to be the wrong level in svn. In the svn repo, we usually try to record svn:mergeinfo at the branch root, e.g. at svn/trunk, whereas the cases git is complaining about seem to pertain to mergeinfo that's attached to particular branch subdirectories, e.g. at svn/trunk/dir1. I'm not a svn expert, but my current heuristic is that if you have a lot of svn:mergeinfos that aren't at the branch root, there may be something amiss with your svn repo or your merging process. If that's right, it's understandable that git would complain. In my own case, I think most of these "weird" commits modify svn:mergeinfo both at the branch root (e.g. svn/trunk) and at the subdir level (e.g. svn/trunk/dir1); git gleans whatever it needs from the root-level, and throws an apparently harmless error about the subdir level.

That said, some people seem to be reporting problems in some case, perhaps especially when rebasing in a git-svn repo where not all the branches were checked out.