我可以对提示和推送进行较旧的修订（使用 Mercurial）吗？
假设我有一个好的修订版本：3200。然后我想测试一些东西，因为它有 10 行更改，我需要删除几行，即使我仍在测试我首先提交，并在进行一些更改后，再次提交，假设我做了 6 次提交。
现在我想搁置这个，但我不想丢失所有测试和编写的代码，所以我想知道
$ hg up -r 3200
哪个是我想要的良好、稳定的修订版，现在我可以提交并推送作为提示吗？ （如果可能的话，我想避免回滚 hg backout 因为它看起来有点糟糕，而且我不想回滚，因为回滚有副作用“如果有人在这段时间从我身边拉出来，更改可以以某种方式回到回购协议中”）
Say if I have a good revision: 3200. Then I want to test something, and since it has 10 lines of change, and I need to remove a few lines, even though I am still testing I commit first, and after some changes, commit again, and let's say, I did 6 commits.
Now I want to put this on hold, but I don't want to lose all the testing and code written, so I want to
$ hg up -r 3200
which is the good, stable revision I want, and now can I commit and push as the tip? (if possible I want to avoid backing out hg backout because it looks bad somewhat, and I don't want to rollback because rollback has side effect of "if someone pulled from me during this time, the change can somehow get back in the repo")
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 Mercurial 中，可以通过多种方式暂停事务。最简单的方法就是不要将其推到任何地方。返回历史记录后，
您可以使用
仅推送到修订版 3200。
.很重要 - 它意味着工作副本父修订版，在本例中为 3200。修订版 3200 不会是“提示”在您的本地存储库中，因为您仍然有修订版 3201–3206，并且编号最高的修订版始终就是我们所说的“tip”。换句话说，历史记录如下所示：我在其中标记了当前工作副本父修订版和提示修订版。
当您开始基于修订版 3200 进行工作时，图表将变为
请尽量不要过多强调“提示”。它一直在变化，而且通常不是很有趣。如果您跳回 3206 并进行提交，则提示将表示存储库中新创建的修订版 3208。在另一个存储库中，提示可以是其他内容，具体取决于从您那里提取的内容以及提取的时间。
如果您经常需要执行
hg Push -r .，那么我建议您创建一个 别名。这样的别名将是一个更温和的推送，因此可以称为“轻推”：有了工具箱中的别名，您始终可以将
刚刚创建的变更集发送到服务器，而不必担心发送任何其他分支你可能已经搁置了。
最后，请记住您可以将
3206 变更集标记为“已关闭”。这意味着它不会出现在
hg head中，并且在运行hg merge时不会考虑合并。如果您将其推送到服务器，您将需要使用hg push --force，但是没关系，因为您没有创建多个开放头，您只需添加另一个封闭的头。多个开放头的问题实际上是，一个新的
hg 克隆可能会更新为其中一个，这会令人困惑 - 人们不知道从哪里开始工作。对于最新版本的 Mercurial，hg clone不会更新为封闭头，因此您可以避免此问题。您可以通过简单地基于它进行子提交来重新打开封闭的头。这意味着您可以暂时关闭开发线而不会产生任何不良影响，除了图中指出分支在某个时刻关闭的注释之外。
Putting things on hold can be done in several ways in Mercurial. The simplest way is to simply not push it anywhere. After you go back in history with
you can use
to push only up to revision 3200. The
.is important — it means the working copy parent revision, which in this case is 3200. Revision 3200 wont be "tip" in your local repository since you still have revisions 3201–3206, and the highest numbered revision is always what we call "tip". In other words, the history looks like this:where I've marked the current working copy parent revision and the tip revision.
When you start working based on revision 3200, the graph will change into
Please try not to add too much emphasis on "tip". It changes all the time and is generally not very interesting. If you jump back to 3206 and make a commit, then tip will denote the newly created revision 3208 in your repository. In another repository, tip can be something else, depending on what was pulled from you and when it was pulled.
If you often need to do
hg push -r ., then I suggest you create an alias for it. Such an alias would be a gentler push and could therefore be called "nudge":With that in your toolbox, you can always do
to send the changesets you've just created up to the server, without worrying about sending up any other branches that you might have put on hold.
Finally, remember that you can use
to mark the 3206 changeset as "closed". This means that it wont show up in
hg headsand it wont be considered for merging when you runhg merge. You will need to usehg push --forceif you push it to the server, but and is okay since you're not creating multiple open heads, you just add another closed head.The trouble with multiple open heads is really that a new
hg clonemight update to one of them and that would be confusing — people wouldn't know where to start working. With recent versions of Mercurial,hg clonewon't update to closed heads so you avoid this problem.You can re-open a closed head by simply making a child commit based on it. This means that you can close a line of development temporarily with no ill effects, other than a note in the graph saying that the branch was closed at some point.
从问题和附带的评论来看，听起来您希望所有新的更改都基于 3200，而将之前基于 3200 的工作作为一个单独的分支。这很容易做到：
但据我所知，没有任何方法可以将 3200 标记为小费。一旦您提交了基于 3200 的内容，新的变更集将成为提示，因此您可以进行一些良性更改并提交它以创建新的提示，但这有点混乱。如果您担心其他协作者不知道使用 3200 作为他们工作的基础，因为 Mercurial 不会将其标记为提示，则另一种选择是给它一个标签并告诉团队成员确保并更新他们的工作副本在开始工作之前添加到该标签。
From the question and the accompanying comments, it sounds like you want all new changes to be based on 3200, leaving previous work based on 3200 as a separate branch. It's easy to do:
but there isn't any way to mark 3200 as tip, as far as I can tell. Once you commit something based on 3200, that new changeset will be tip, so you could make some benign change and commit that to create the new tip, but that's kind of kludgy. Another option if you are concerned that fellow collaborators won't know to use 3200 as the basis for their work because mercurial won't have it marked as tip is to give it a tag and tell team members to make sure and update their working copy to that tag before beginning their work.
krupans 的回答当然是正确的，他已经提到了现在有两个头的问题。但我想强调的是，您将拥有同一个分支的两个头，其他人可能很难理解发生了什么以及使用哪个头。
因此，将测试代码放入新分支可能会有所帮助，为此您必须重写历史记录。您可以使用 MQ 扩展来执行此操作（假设 3201 是 rev 3200 的子修订版本，3206 是您的最后一个测试提交：
在您的存储库的克隆上尝试此操作！
仅当您还没有这样做时才应该这样做已经将这些更改推到了其他一些地方。
krupans answer is of course correct, and he already mentions the problem of having now two head. But I'd like to stress that you will then have two heads of the same branch, and it could be difficult for other people to understand what's going on, and which head to use.
For this reason, it might be beneficial to put your testing code into a new branch, and for that you'll have to rewrite the history. You can do this with the MQ extension (assuming 3201 is the child revision of of rev 3200, and 3206 is the last of your testing commits:
Try this out on a clone of your repo!
This should only be done if you haven't already pushed these changes to some other places.