5

我将 svn 用于我与其他几个开发人员合作的项目。Svn 可以很好地用于源代码控制，但是当我们提交 dll 时，我们总是会遇到冲突。

当我这样做时，我解决了冲突（由于 diff 程序无法处理二进制文件而删除了我的 dll），然后必须重新构建才能提交。你打算如何解决这样的冲突？

编辑：

dll 位于单独的 svn 文件夹中，因为该项目是一个游戏模组，非程序员需要访问最新版本。

4

7 回答 7

8

如果它是您正在构建的 DLL（而不是您没有源代码的外部），那么源代码应该在源代码控制中，而不是二进制文件。

如果您不想将其包含在该特定存储库中，则可以将其包含为 svn:external。

于 2009-01-04T09:45:37.653 回答
7

正如此处的其他答案所述：您不应该首先对生成的 dll 进行版本控制。但是，如果您真的必须对它们进行版本控制，那么您可以在不使用删除 dll 文件的 diff 工具的情况下解决冲突：

对于每个冲突的文件，Subversion 会在你的工作副本中放置三个额外的未版本控制的文件：

文件名.mine

这是您在更新工作副本之前存在于工作副本中的文件，即没有冲突标记。该文件仅包含您的最新更改。（如果 Subversion 认为该文件不可合并，则不会创建 .mine 文件，因为它与工作文件相同。）

文件名.rOLDREV

这是更新工作副本之前的基本修订文件。也就是说，您在进行最新编辑之前签出的文件。

文件名.rNEWREV

这是您的 Subversion 客户端在您更新工作副本时刚刚从服务器收到的文件。此文件对应于存储库的 HEAD 修订版。

这里 OLDREV 是 .svn 目录中文件的修订号，NEWREV 是存储库 HEAD 的修订号。

现在，要解决此类冲突，请删除您不想要的其他文件：

  • 如果您想保留自己的 dll，请删除文件 filename.rOLDREV、filename.rNEWREV
  • 如果要保留存储库中的 dll，请删除文件 filename.rOLDREV 和 filename.mine，然后将 filename.rNEWREV 复制到文件名

之后，执行

svn resolved filename

告诉 Subversion 你自己解决了冲突。

于 2009-01-04T09:50:45.803 回答
3

通常，您根本不会将自己编译的 DLL 存储在源代码管理中。您是否有特定的理由需要这样做？

我设置了我的开发环境，以便任何人都可以独立于其他人构建我的任何项目组件。这样，我的源代码控制系统中唯一的东西就是我的源代码。这有很多好处：

  • 在尝试签入 DLL 或 EXE 时避免二进制文件冲突
  • 源代码控制系统跟踪的数据量要小得多，速度更快
  • 当开发人员总是构建自己的 DLL 时，他们可以合理地确定他们拥有的源代码与编译后的文件相匹配。如果您使用的是其他人构建的东西，那么您永远无法确定。

正如评论中提到的，将第三方 DLL 存储在您的源代码控制系统中是完全合理的，特别是如果您实际上没有它们的源代码。我还参与过一些项目，我们.tar.gz在源代码控制中为各种开源库存储分发文件（等），然后拥有一个完整的Makefiles系统，将这些库构建为 build-everything 目标的一部分。

于 2009-01-04T09:41:47.787 回答
2

对于二进制文件，大多数时候，您希望接受它的任一版本。例如，如果所讨论的文件是一个可执行工具，那么通常一个版本可能比另一个版本新，而这可能就是您想要使用的那个。

要接受您要合并的分支中的版本，请使用：

svn resolve --accept=theirs-full path/to/filename

要接受以前在当前分支中的版本，请使用：

svn resolve --accept=mine-full path/to/filename

有时，SVN 会拒绝使用theirs-full并发出警告：

svn: warning: W195024: Inapplicable conflict resolution option given for conflicted path

因为SVN在合并方面是一团糟。在这种情况下，您必须像在接受的答案https://stackoverflow.com/a/410767/2279059中那样手动复制文件，而不是使用适用于您要执行的操作的命令行选项。如果您知道这两个文件是相同的（但由于已经说明的原因，SVN 仍将它们标记为冲突），您也可以使用

svn resolve --accept=working path/to/filename

虽然在相同文件的情况下，这实际上与所有其他命令相同，但 SVN 不会怯懦地拒绝执行它。这有意义吗？不，它没有。处理它。

于 2018-10-17T13:30:45.890 回答
1

在版本控制中也有二进制文件是合理的：

  • 它避免了只使用二进制文件的人重建的麻烦。

  • 当您发布时，二进制文件已确定。

为了完成这项工作，二进制文件需要始终与源相对应。因此，如果您已合并源，则需要从中重建二进制文件，从合并版本中选择一个二进制文件是行不通的。

于 2009-01-04T10:18:51.487 回答
0

确保您的 dll 将svn:mime-type属性设置为application/octet-stream或其他一些非文本类型。

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

当冲突发生时，您仍然必须实际解决冲突。

并检查文档的文件内容类型章节。

于 2009-01-04T10:17:58.087 回答
0

因此，如果您将 *.dlls 放在单独的文件夹中，则更容易执行以下操作：

  1. 直接在您构建更改之前更新您的 *.dll 文件夹，如果您相信您的同事只提交可编译的源代码，最好也更新您的源代码。（如果发生冲突（此时您的错是什么，因为您在更新到最新版本之前更改了某些内容））
  2. 做你的构建。
  3. 直接提交结果。

或者：

不要构建到目录中的路径，构建到外部的某个地方，直到您对结果感到满意为止。

然后进行如下操作：

  1. 更新您的 dlls 文件夹的工作副本（如果有任何冲突是您的错，并通过“保留他们的”来解决冲突）
  2. 将您的工作 .dll 复制到工作副本
  3. 通知你的同事你将提交一个新的修订（你可以放弃这一步）
  4. 如果有任何冲突，请提交您的工作，这应该是他们的错。

你现在有两种可能：

5a。你是一个非常可恨的人，并通过保留我的来解决问题。

5b。您按照应有的工作方式工作...阅读日志文件并找出在您需要将工作复制到文件夹并按下提交的短时间内还提交了谁。和那个同事谈谈。同意进一步的行动方案。

于 2017-08-16T09:44:47.367 回答