是否有可能通过添加subrepos来重新更新？

我在我的资源库中有一个文件夹。然后，我将这个文件夹作为子库（具有相同的文件），提交并推送此更改。现在我无法通过该提交进行更新。这是我得到的消息：是否有可能通过添加subrepos来重新更新？

% hg update --repository <path to repo> --config ui.merge=internal:fail --rev 1159 --clean 
abort: path 'subrepo\include\header.h' is inside nested repo 'subrepo' 
[command returned code 255 Wed Dec 05 11:57:45 2012]

哪里subrepo就是subrepo现在居住在该文件夹的名称。任何方式来击败这个并更新到早期版本？

来源

2012-12-05 Violet Giraffe

我刚刚有一个“玩”善变，它看起来就像是试图做一个更新回你有subrepo把工作目录中的“奇”状态之前。例如，之后执行“hg update -C”会尝试恢复文件，但不会正确设置工作目录状态（对我而言）。 'hg summary'报告父母是'-1：000000000000'，没有检出修订。目前，我正在想这可能是一个错误报告 - 会多打一些... – icabod

@icabod：感谢您的时间，希望能为进一步的调查结果。 –

发现了一个“解决方案”：删除该文件夹并将其更新没有问题（用“放弃更改”选项）。

来源

2012-12-05 16:14:49

但是请注意，在删除该文件夹有丢失所以在该subrepo库本地的修改的可能性。听起来你的情况并不是问题，但是如果别人没有意识到数据丢失的可能性，这可能会导致严重的问题。 – davidmc24

@ davidmc24：好点，尽管任何Mercurial用户都应该明白，没有提交和推送的更改将会丢失。我不认为有任何问题提交，并且无论主要的回购状态如何，都会对该子存储库进行更改。 –

经过一番Google搜索，看起来它与Caveat 3直接相关，引用“当前无法删除子库的更新/合并，因为这可能会丢失仅本地更改”。另外需要注意的是，“正常文件和subrepos之间的冲突没有处理”。

有趣的是，我之前没有见过的东西，子版本库被认为是“feature of last resort”，这就是说，如果您可以帮助它，就应该尽量不要使用。

可能不是你要找的答案。

一种解决方法是通过克隆到你的修订......你可以使用一个新的克隆基于某个版本创建的subrepo之前：

% hg clone --repository <path to repo> new_copy --rev 1159

这一切克隆到这一点，所以你会失去任何“未来的历史”，但至少能够回到以前的版本。

来源

2012-12-05 15:01:57 icabod

哦，好的。如果我只知道这些警告......谢谢。 –

您可以克隆回购高达以前的版本，但还没有找到一种方法来在同一回购内更新。 – icabod

完美！我怀疑它应该是可能的，但还没有找到命令。这将会诀窍。 –

是否有可能通过添加subrepos来重新更新？

回答

相关问题