修复 Mercurial 中移动的文件之间的链接
在拥有这个存储库（最初是 SVN）的过程中，我不太擅长将文件链接保持在一起。我已经更改了 IDE 两次，将项目拆分为 Netbeans 模块，并随着时间的推移对项目进行了优化。大部分文件历史记录都丢失了，主要是因为在mavenizing期间我删除了整个主干，提交，复制到maven项目，然后提交。这不完全是最好的主意，因为我后来发现所有历史记录都重置为该点。它变得如此糟糕，以至于存储库统计程序毫无用处，因为它说我投资了 50,000 行代码，而不是大约 8,000 行。
有什么方法可以修复所有损坏的文件历史记录吗？如果 Mercurial 无法访问，我可以访问 SVN 和 Git
Over the course of having this repo (originally SVN) I've not been to good with keeping file links together. I've changed IDE's twice, split the project into Netbeans modules, and mavenized the project over its time. Most of the file history is lost, mainly because during mavenizing I deleted the entire trunk, committed, copied over the maven project, and committed. Not exactly the best idea, as I later found out all history reset to that point. Its gotten so bad that a repository stats program is useless since it says I have 50,000 lines of code invested instead of ~8,000.
Is there any way to fix all the broken file histories? I have access to SVN and Git if Mercurial can't do it
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，当你执行删除和复制时，如果你刚刚执行了
hg addremove --similarity 90，它会说“删除所有已消失的内容，添加所有新内容，并且如果它们彼此有 90% 相似，算作重命名”。既然这个机会已经过去了，那么就无法在不重写存储库的情况下移动一个存储库，这会导致所有节点 ID（哈希值）发生变化时所有的克隆都失效。如果没关系，并且您有一个很大程度上是线性的历史记录，您可能可以通过这样的方式度过：
这需要从您的第一次提交到最后一次提交的线性历史记录（不包括分支和其他头等）将它们导出到补丁，创建一个新的清空存储库，并使用重命名检测功能导入变更集。
这是一个相当激烈的行为，因此请确保它对您来说确实值得，并保留您的旧存储库以备不时之需。
Hrm, and the time you did your delete and copy you'd've been fine had you just done
hg addremove --similarity 90which says "remove everything that's gone, add everything that's new, and if they're 90% similar to one another count is as a rename".Now that that opportunity has passed there's no way to move one w/o re-writing your repository, which invalidates all the clones out there in the wild as all the node ids (hashes) change. If that's okay and you have a largely linear history you can probably get by with something like this:
That takes a linear history from your first commit to your last (excluding branches and other heads, etc.) exports them to patches, creates a new empty repo, and imports the changesets using the rename detection feature.
This is a pretty drastic act so make sure it's really worth it to you and keep your old repo around for good measure.