Menu
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?
844
In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the svn.noMetadata section above for details). git svn fetch and git svn rebase automatically update the rev_map if it is missing or not up to date. git svn reset automatically rewinds it.
This option may be changed while git svn is running and take effect on the next revision fetched. If unset, git svn assumes this option to be "true". This instructs git svn to recode pathnames to a given encoding. It can be used by windows users and by those who work in non-utf8 locales to avoid corrupted file names with non-ASCII characters.
In SVN we required Network for runs the SVN operation. Git is more difficult to learn. It has more concepts and commands. SVN is much easier to learn as compared to git. Git deals with large number of files like binary files that change quickly that why it become slow.
The particular delta compression algorithms used in both version control systems differ in many details, but in general Subversion and Git store data in the same way. This results in the fact that Subversion and Git repositories with equivalent data will have approximately the same size.
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.
123
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
