1

我使用 Jenkins 从我的 Android 项目中获得了一个自动构建系统，该系统通过 SVN 同步。有时我会在工作区中添加新文件，我认为这些文件来自冲突的 SVN 进程。当资源文件夹中发生这种情况时，它会导致构建失败，因为文件扩展名被剥离并且存在名称空间冲突。

例如

 [aapt] res\drawable\icon.png.r584:0: error: Resource entry icon is already defined.
 [aapt] res\drawable\icon.png:0: Originally defined here.
 [aapt] res\drawable\icon.png.r588:0: error: Resource entry icon is already defined.
 [aapt] res\drawable\icon.png:0: Originally defined here.

知道为什么我会得到这些 r584、r588 文件吗？可能更重要的是，我该如何阻止这种情况发生？

虽然 jenkins 构建是机器本地的，但我工作的原始 SVN 目录位于保管箱管理文件夹中（不要问！）。虽然我不认为这是一个问题，但我觉得我应该提到它，以防万一它确实有一个促成因素。

这些.r??? 我的原始源代码树或 SVN 结构中不存在文件，因此据我所知，只能通过 Jenkins 完成的 SVN 同步操作来制作。

4

3 回答 3

3

它们看起来像冲突标记 - 当您合并时，如果它无法自动解决问题，它将在目录中放置 2 个临时文件，并将修订号作为文件扩展名的一部分。你应该使用 diff 应用程序来决定最终文件应该是什么样子，然后告诉 svn 你已经解决了冲突。然后 SVN 将删除旧的临时文件并让您提交更改。

您的提交今天将有垃圾 - 如果您查看同名文件，您会看到源代码中嵌入的差异标记。我很惊讶你可以提交，但我猜保管箱副本在某种程度上影响了这种情况 - 你是提交增量还是只是检查目录，就好像它是一堆新文件一样？

于 2013-01-21T12:56:38.450 回答
2

正如其他人所说，*.rNNN 是 SVN 合并冲突，其中 NNN 是冲突的修订号。同样，就像其他人所说的那样，Jenkins 必须是工作区的所有者，而不是其他东西。

让我试着在这里澄清一些事情。你说"the original SVN directory I work in is inside a dropbox managed folder (don't ask!)."。你是说：

a）您正在为 Jenkins 使用自定义工作区（您将不得不为此使用自定义工作区设置）
b）您（用户的）工作目录是一个保管箱管理的文件夹

如果 b) 为真，那没关系。但如果 a) 为真，这可能会导致各种问题。如果是这种情况，你真的需要让 Jenkins 管理自己的工作空间。是的，这可能意味着空间需求的两倍，但这是应该的方式。

现在，假设 Jenkins 的工作空间由 Jenkins 管理，它首先会尝试做的是SVN Update. 这绝不会导致合并问题（那些 *.rNNN 文件），除非某些东西正在修改工作空间。同样，如果 a) 点成立，请考虑为 Jenkins 提供自己的工作空间。构建本身可能正在修改工作区（我不熟悉 Android 构建或它对文件的作用）。

在任何一种情况下，您都想要做一个干净的 SVN 结帐。有两个选项适合您。

  • 总是检查一个新的副本
  • 在更新前使用 'svn revert' 尽可能使用 svn update

这两者都可以在作业配置中的“源代码管理”下的“签出策略”下找到。

第一个将清理 Jenkins 工作区并进行完整的结帐。这可能更长，但“更干净”。

第二个将尝试在进行 SVN 更新之前恢复对工作区的任何本地更改，从而消除合并冲突。

于 2013-01-21T15:54:56.463 回答
1

AFAIK，* .r### 文件就像你建议的那样，当与被检出的内容发生冲突时。（我试图找到一个好的参考，但没有。不过我自己也看过。）

由于这些通常发生在结帐时发生冲突时，因此我会考虑一些事情来解决这个问题。

  1. 确保在 Jenkins 工作区中签出的文件没有被修改。如果它们应该被该过程修改，您可能需要查看强制 SVN checkout to overwrite的答案。
  2. 检查目录的权限与运行 Jenkins 的用户的权限。

一般来说，Jenkins 应该是工作区的所有者和唯一的操作者，以处理它正在运行的任何作业。

于 2013-01-21T12:57:20.410 回答