运行git svn clone
并经常在后续的git svn fetch
操作中运行时,我收到了许多文件夹的消息:
Couldn't find revmap for <SVN folder URL>
我的存储库似乎正常工作。这条消息是什么意思?我应该关注它吗?
答案 0 :(得分:35)
我没有完整的答案,但此错误是由git-svn.perl生成的。 (相关的代码路径似乎是do_fetch - &gt; make_log_entry - &gt; find_extra_svn_parents - &gt; lookup_svn_merge。)该代码似乎试图查看svn merge commit的svn:mergeinfo属性以找出其所有父提交/分支,希望在git clone中将其变成一个漂亮的多父合并提交。如果该父分辨率失败,您的提交仍将被提取到git中;它只是没有相同的父信息。
到目前为止,我还没有亲自发现当前主要用例的错误导致的任何大问题,即将svn repo转换为git; git-svn已经能够解决对我来说真正重要的大合并,到目前为止这些错误似乎仅限于单独的樱桃选择合并或我不再关心的旧分支。
实际上,乍看之下,在我的情况下,大多数这些错误都源自于svn:mergeinfo被记录在我认为是svn中的错误级别的提交。在svn repo中,我们通常尝试在分支根处记录svn:mergeinfo,例如在svn / trunk,而git抱怨的情况似乎与附加到特定分支子目录的mergeinfo有关,例如在svn / trunk / dir1。我不是一个svn专家,但我目前的启发式是,如果你有很多不在分支根目录的svn:mergeinfos,你的svn repo或你的合并过程可能有些不对劲。如果这是正确的,git会抱怨是可以理解的。在我自己的情况下,我认为大多数这些“奇怪的”提交都修改svn:mergeinfo在分支根(例如svn / trunk)和在子目录级别(例如svn / trunk / dir1); git从根级别收集它需要的任何东西,并抛出一个关于子目录层的明显无害的错误。
尽管如此,有些人似乎在某些情况下报告问题,尤其是在rebasing in a git-svn repo where not all the branches were checked out时。
答案 1 :(得分:2)
只是想注意 - git-svn中实际存在一个隐藏文件,称为
.git/svn/refs/remotes/git-svn/.rev_map.00088888-caaa-4444-9999-2222eeeeeee4
...其中结束标识是存储库UUID或git-svn-id
。
这是一个二进制文件,/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.
请注意,输出看起来像这样:
$ 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..`...
我认为当您键入git svn info
时,会查询此文件,以便根据提交的git
SHA哈希获得SVN修订号。我不知道怎么可以重建它(althogh git svn reset
可能有助于从这个文件中删除条目,而不是100%肯定不会这样)