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 find revmap for <SVN folder URL>

My repository seems to work fine. What does this message mean? Should I be concerned about it?

Answer 1

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.