perforce是否在与取消搁置存在冲突后安排解决？

我试图理解当文件在工作区中被取消搁置时，perforce时间表是如何解决的以及为什么会解决的。我认为这是我（一个P4新手）还没有完全掌握的基本知识，但FWIW，P4信息给了我一个版本。。。服务器版本：P4D/LINUX26X86_64/2013.2/938876（2014/09/23）

假设一个用户将他们的工作区同步到depo head，“file.txt”是版本8（file.txt#8）。然后，另一个用户提交一个更改，这样在depo中，它现在是“file.txt#9”。第一个用户搁置文件.txt#8，移动到另一个目录，在那里他同步整个仓库的负责人（包括文件.txt#9）。那个工作区现在有9个。然后他执行p4取消搁置，文件.txt#8现在在默认更改列表中

此时，用户担心与#8之后可能出现的冲突，因此他执行“p4 resolve-am”。在那一点上你希望看到什么？文件.txt#8？文件.txt#9？8和9的合并版本？我想我们看到的是file.txt#8，但我们希望看到一个合并版本。我想知道我们是否必须在取消搁置后通过某种同步来“安排”解决方案。但是，如果我们进行同步，文件.txt#8中的更改是否仍会以某种方式保留下来，或者同步是否会使它们崩溃

---

提前感谢您的解释。

逐步完成此步骤：

用户同步到#head，“file.txt”的版本为8（file.txt#8）

该文件位于他们的工作区中，版本为#8。它不允许任何行动

另一个用户提交了一个更改，在仓库中，它现在是“file.txt#9”

该文件仍在版本为#8的用户工作区中，尚未打开

第一个用户搁置文件.txt#8

等等--用户如何在不打开的情况下将其搁置？我将在这里填补一个空白，并假设他们：

• 打开文件进行编辑（

  p4 edit

  ）
• 对文件进行了更改（因此现在它有了与

  file.txt#8

  相关的更改）。我称之为“改变X”

移动到另一个目录，在那里他同步整个仓库的负责人（包括文件.txt#9）。那个工作区现在有9个

等等--这是同一工作区中的另一个目录，还是完全不同的工作区？如果它是同一个工作区，那么它们在不同的目录中并不重要。既然你说他们有

file.txt#9

，我就假设它是另一个工作区，因为我已经假设该文件在原始工作区中打开，并且如果该文件已经打开，同步实际上不会拉下新版本

我将把原始工作区称为“客户机A”，而这个新工作区称为“客户机B”

然后他执行p4取消搁置，文件.txt#8现在在默认更改列表中

好的，酷。因此，现在我们所处的状态是，该文件已有效地同步回

file.txt#8

，并已打开进行编辑，并且工作区中已更改X。当您取消搁置文件时，它始终同步到搁置文件的同一版本，即使您以前在工作区中同步了更高版本的文件。（如果以前同步了较新版本的并打开了，则取消搁置会立即安排解决，但您描述的情况并非如此。）

换句话说，对于

file.txt

，客户端A和客户端B处于完全相同的状态。它在#8打开，更改X在工作区中

此时，用户担心与#8之后可能出现的冲突，因此他执行“p4 resolve-am”。在那一点上你希望看到什么

什么也没有发生，因为文件仍然同步到#8。在同步到需要解析的较新版本之前，不会计划解析。（这允许您选择解决哪些修订以及何时解决——如果提交了多个较新的更改，您可以通过仅同步这些更改来“挑选”解决哪些修订，或者通过同步到#head来解决所有修订。）

我想知道我们是否必须在取消搁置后通过某种同步来“安排”解决方案。但是，如果我们进行同步，文件.txt#8中的更改是否仍会以某种方式保留下来，或者同步是否会使它们崩溃

是的，你必须进行同步，不，同步不会影响X，因为它是开放的，可以编辑。同步将安排解析，然后解析的任务是将#9（他们的）与X（你的）合并

---

事实上，通过取消搁置实现的更改并不重要——重要的是，当文件在较旧版本中打开进行编辑时，

sync

ing到较新版本会安排针对该版本的解决方案。无论您在客户端A还是客户端B中执行此操作，您都会看到相同的行为，因为两者的状态完全相同（文件在#8打开）。

谢谢Samwise：是的，您在#8的打开/修改版本和新工作区上猜对了。感谢您确认我们必须进行同步以“安排”解决方案，并且对#8的更改不会被破坏。