1

我们需要重构代码库。问题是这将由一个人完成，并且最好避免让开发团队的其他成员在这项工作发生时无所事事。因此，我们尝试了以下场景，看看是否可以并行工作。

  1. 首先在开发人员 A 的工作区中的目录中创建文件 test.txt。
  2. 推广了这个文件。
  3. 更新了开发者 B 的工作空间，从而得到文件 test.txt
  4. 在 A 的工作区中，将文件 test.txt 移动到目录第二个。
  5. 推动了这一举措。
  6. 在 B 的工作区编辑的文件 test.txt 中，它仍然首先驻留在目录中（不进行更新，从而模拟在进行重构时已完成工作）。
  7. 尝试推广并收到一条消息说文件 test.txt 已被修改（正确，文件已被移动）。
  8. 尝试合并，但收到一条错误消息，指出 AccuRev 无法合并，因为该文件在第二个目录（已移动的位置）中丢失。
  9. 试图更新 B 的工作区，但这是不允许的，因为有一个修改过的文件需要先合并。

我们现在陷入了第 22 条问题。我们确实尝试在第二个目录中放置一个假文件，但由于该文件不属于工作区，因此无法识别。

有没有人尝试过这样的事情并让它工作？当然可以复制文件，但如果有更好的方法，我们将不胜感激。或者，如果这是工具中的已知错误或限制。我们将联系 AccuRev 支持，但我认为我可能能够从社区获得一些有用的提示。

目前我们正在使用 AccuRev 客户端 5.5.0。

感谢您提供有关如何使该工具支持此操作的任何建议。

4

3 回答 3

0

我可以使用 AccuRev 5.5 实验性地验证 David 对第 9 步的评论。

假设在用户 A 的工作区中，文件被移动并被提升，而在用户 B 的工作区中，文件被修改，用户 B 即将提升他/她的更改。

在保存文件之前，用户 B 既不能合并也不能更新。但在保留修改后的文件后，更新是可能的。该文件首先被标记为重叠，然后合并在新位置成功。基本上，这避免了创建文件的副本、还原它并在更新后将其恢复到新位置，这可能非常麻烦，因为 AccuRev 不能轻易地揭示移动的位置。

如果用户 B 在用户 A 推动移动之前推动修改，则一切顺利，即在更新时，移动的文件显示为重叠，但很容易在新位置合并到移动的文件中。

当两个用户的工作空间连接到不同的流并且重叠发生在共同的父流上时，会获得类似的结果。仅当文件未被保留时，才会发生错误（即仅当移动在更改之前被提升时）。然后一个简单的保持允许照常进行（更新，合并，然后提升）。

于 2014-05-15T08:26:04.263 回答
0

在与 AccuRev 支持人员联系后，唯一可用的选项是将文件复制到某个临时目录、还原更改、更新工作区并将文件复制到工作区中的新位置。

AccuRev 至少会告诉您必须复制哪些文件，因为它们将被标记为已修改。

于 2013-12-05T13:14:43.367 回答
0

参考您的第 6 步和第 7 步：在 AccuRev 5.5 中，文件被编辑并具有（修改）状态后，您首先必须保留才能进行升级。

在第 8 步，您可以尝试从文件的 Browse Versions 视图进行合并。这样，您可以选择要合并的任何节点，包括已移动的节点。

步骤 9. 如果要更新的文件之一是（已修改），则 AccuRev 更新将不会成功运行。这是设计使然。您可以保留文件，使其具有（保留）（成员）状态，然后运行更新。

大卫豪兰

于 2013-12-02T14:28:31.540 回答