为什么 git-cvsimport 缺少一个主要补丁集？
我可以查看 cvsps 的输出（保存在我的 ~/.cvsps 目录中）并查看主要的、复杂的提交的补丁集。 但是当我执行 cvsimport 来更新现有的 git 存储库时，此提交不会显示。 我知道 git-cvsimport 将忽略更新时间超过 10 分钟的补丁集，以避免导入不完整的 CVS 提交。 我想我还听说它将跳过无法识别关联分支的补丁集。 还有哪些其他原因可能导致 git-cvsimport 忽略我的提交？ 我该如何调试这个？
这是 cvsps 输出的一些内容：
patchset: 50064
date: 1238445635
author: skiphoppy
tag:
tag_flags: 0
branch: HEAD
branch_add: 1
descr:
My log message
-=-END CVSPS DESCR-=-
members:
file:ordinaryChangedFile; pre_rev:1.44; post_rev:1.45; dead:0; branch_point:0
file:newFileRenamedAndModifiedFromOldFile; pre_rev:INITIAL; post_rev:1.1; dead:0; branch_point:0
file:deletedFileGoneBecauseRenamed; pre_rev:1.2; post_rev:1.3; dead:1; branch_point:0
...
branch_add: 1 行与它有什么关系吗？ 整个存储库中只有 9 个这样的提交； 其他 50090 次提交说branch_add: 0。除此之外，我不知道从 cvsps 或 git-cvsimport 的角度来看有什么区别。 提交很复杂，涉及重命名多个文件并进行相关内容修改。 CVS 绝对很难处理。 当然，这对于 git 来说是一个快照，但是当真正的后端是 CVS 时，git 很难处理。
我必须再执行三次相同类型的复杂提交，而且由于 cvsimport 无法看到我的提交，我无法每次花费 4 1/2 小时从 CVS 重新导入全新的 git 存储库。
更重要的是，我担心我每天运行的 git-cvsimport（我打算将其放入 cron 中，甚至编写一个守护进程每五分钟左右运行一次）可能会错过 承诺未来！ 我发现没有办法 git 现有的存储库来获取这些提交； 我只能在一个全新的存储库中运行 git-cvsimport 并永远等待，从而失去了对许多其他分支的使用。
This is a followup to a previous question of mine.
I can look through the output of cvsps (saved in my ~/.cvsps directory) and see a patchset for a major, complicated commit. But this commit does not show up when I do cvsimport to update my existing git repository. I know that git-cvsimport will ignore patchsets that are newer than 10 minutes, in an effort to avoid importing a CVS commit that is incomplete. I think I've also heard that it will skip patchsets for which the associated branch cannot be identified. What other reasons might be causing git-cvsimport to be ignoring my commit? How can I debug this?
Here is a little bit of the cvsps output:
patchset: 50064
date: 1238445635
author: skiphoppy
tag:
tag_flags: 0
branch: HEAD
branch_add: 1
descr:
My log message
-=-END CVSPS DESCR-=-
members:
file:ordinaryChangedFile; pre_rev:1.44; post_rev:1.45; dead:0; branch_point:0
file:newFileRenamedAndModifiedFromOldFile; pre_rev:INITIAL; post_rev:1.1; dead:0; branch_point:0
file:deletedFileGoneBecauseRenamed; pre_rev:1.2; post_rev:1.3; dead:1; branch_point:0
...
Does that branch_add: 1 line have anything to do with it? There are only 9 such commits in the entire repository; the other 50090 commits say branch_add: 0. Other than that I don't know what the differences are from a cvsps or git-cvsimport point of view. The commit was complicated, involving renaming several files and making associated content modifications. Definitely difficult for CVS to handle. A snap for git, of course, but hard for git to handle when the real backend is CVS.
I've got to perform the same type of complicated commit three more times, and I can't afford to spend 4 1/2 hours each time to reimport a brand new git repository from CVS due to cvsimport not being able to see my commit.
More importantly, I'm frightened by the fact that my daily runs of git-cvsimport (which I intended to put into cron, or even write a daemon to run every five minutes or so) might miss commits in the future! I have found no way to git an existing repository to pick up these commits; I can only run git-cvsimport in a brand new repository and wait forever, losing the use of many of my other branches while I'm at it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
嗯，这可能就是问题所在。 我的 git-cvsimport 行如下所示：
-px 应该将 -x 选项传递给 cvsps，告诉它忽略之前运行时留下的缓存输出。 我认为这样做的主要原因是，最后几个可能不完整的补丁集将被丢弃并在下次运行时完成。 事实证明，它可能修复了更多问题，这可能就是其中之一。
我从 这个博客条目< 学会了以这种方式运行 git cvsimport /a>，目前是 Google 上“git cvs”点击率最高的内容之一。 仅在上面的过程中，我尝试通过 Perl 调试器对 cvsps 的输出运行 git-cvsimport，我才必须检查并查看哪些参数真正传递给 cvsps。 我了解到 cvsps 是这样运行的：
而不是：
当传递 x 而不是 -x 时，我通过实验验证了我从 cvsps 得到了不同的输出，缺少一些补丁集（我不知道模式是什么）。 由于墨菲定律，cvsps 似乎没有报告这是一个问题，而 git-cvsimport 也从未发现过它。
所以无论如何， git cvsimport 需要像这样运行：
我以前版本的这个存储库此时已经完全被处理了，但是我已经能够强制最后一个问题提交到它们中（尽管一些早期的提交丢失了） ）。 所以我又要经历一次四小时的导入过程，我希望就这样！
最后一点提示：Windows 上的 git-cvsimport 似乎根本不起作用。 尽管我最终得到了一棵类似于我们项目当前状态的树，但我得到的提交数量还不到 10%。 它似乎缺乏几乎所有的历史......
Well, this may be the problem. My git-cvsimport lines look like this:
The -p x is is supposed to pass the -x option to cvsps to tell it to ignore the cached output that it left lying around from previous runs. I thought the main reason to do that was so that the last few patchsets, which might be incomplete, will be thrown out and completed the next time you run. Turns out there may be more issues that it fixes, and this may be one of them.
I learned to run git cvsimport this way from this blog entry, which is currently one of the highest hits on Google for "git cvs." It was only in the process above, where I was trying to run git-cvsimport through the Perl debugger on output from cvsps, that I had to check and see what arguments were really going to cvsps. I learned cvsps was being run like this:
Instead of:
And I experimentally verified that I get different output from cvsps, with some patchsets missing (I have no idea what the pattern is), when x is passed instead of -x. Thanks to Murphy's law, cvsps doesn't seem to report that this was a problem, and git-cvsimport never sees it.
So anyway, git cvsimport needs to be run like this:
My previous versions of this repository are completely hosed at this point, but I have been able to force the last of the problem commits into them (some of the earlier commits are missing, though). So I get to go through the four-hour import process one more time, and I'm hoping that will be it!
One last tip: git-cvsimport on Windows doesn't seem to work at all. I got less than 10% of the number of commits, although I did wind up with a tree that resembles the current state of our project. It just seems to be lacking almost all the history...
多谢！ 我遇到了同样的问题，并且可以在您的帮助下解决它！
我什至找到了一种避免从头开始重新运行 cvsimport 的方法。 只需将“master”和“origin”分支设置为较旧的 git 提交，cvsimport 就会重新导入补丁，因为包括丢失的补丁：
找到比丢失的提交更旧的提交 ID：
让“origin”指向该提交
切换到origin（这样“master”就不是当前的HEAD）
现在也使“master”指向旧的提交
切换回master
，时间已完全回滚，您可以再次执行 cvsimport，这次正确
Thanks a lot! I had the same problem and could fix it with your help!
I even found a way to avoid re-running cvsimport from scratch. Simply setting the 'master' and the 'origin' branch to older git commits made cvsimport re-import the patches since that including the missing ones:
find a commit ID older than the missing commits:
make 'origin' point to that commit
switch to origin (so that 'master' is not the current HEAD)
now make 'master' point the older commit as well
switch back to master
now, time is completely rolled back and you can do the cvsimport again, this time properly
我最近遇到这样的事情 - CVS 中有一个提交，在 git cvsimport 后没有出现在 git 中； 后来的提交确实如此（这让我很难受，因为我后来生成了不起作用的补丁。
但是，修复很简单而且愚蠢 - 我只是在丢失的提交之前重置了 cvs/master 分支，重新运行 git cvsimport ，然后它就在那里。
I encountered such thing recently - there was a commit in CVS that didn't show up in git after git cvsimport; later commits did (it bit me hard, because I produced nonworking patches afterwards.
However, the fix was simple and stupid - I just reset the cvs/master branch before the missing commit, rerun git cvsimport, and there it was.
嗯，好消息是 git-cvsimport 似乎是用 Perl 编写的，而我恰好是一名 Perl 程序员，所以也许我至少可以使用 Perl 调试器单步执行此操作，以找出提交期间发生的情况。
对于任何想要尝试此操作的人，您必须找到 git-cvsimport 的完整路径，并使用 -d 开关将其提供给 perl （Perl 解释器）：
我还没有解决所有其他选项这个，但是...我认为我需要直接向 git-cvsimport 提供 cvsps 的输出...
Hmm, the good news is that git-cvsimport appears to be written in Perl, and I happen to be a Perl programmer, so maybe I can at least step through this with the Perl debugger to find out what happens during that commit.
For anyone who wants to try this, you'll have to locate the full path to git-cvsimport and feed it to perl (the Perl interpreter) with the -d switch:
I haven't gotten all the other options worked out to do this, yet ... I'll need to feed git-cvsimport the output of cvsps directly, I think...