解决svn二进制冲突

Question

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

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

编辑：

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

Answer 1

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

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

Answer 2

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

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

filename.mine

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

filename.rOLDREV

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

filename.rNEWREV

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

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

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

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

之后，执行

svn resolved filename

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

Answer 3

通常，您根本不会将自己编译的DLL存储在源代码管理中。你有特殊原因需要这样做吗？

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

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

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

Answer 4

大多数情况下，对于二进制文件，您都希望接受其中的任何一个版本。例如，如果所讨论的文件是一个可执行工具，则通常一个版本可能比另一个版本新，而这可能就是您要使用的版本。

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

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不会胆怯地拒绝执行它。这有意义吗？不，不是。处理它。

Answer 5

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

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

• 释放后，二进制文件会被确定。

要使这项工作，二进制文件需要始终对应于源。 因此，如果您有合并的源，则需要从它们重建二进制文件， 从合并版本中选择一个二进制文件不会。

Answer 6

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

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

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

并查看文档的File Content Type章节。

Answer 7

因此，如果您将* .dll放在一个单独的文件夹中，则更容易完成，如下所示：

1. 在您构建更改更新之前，* .dll文件夹更好地更新您的源，如果您信任，您的同事只提交可编译的源代码。 （如果发生冲突（当你在更新到最新修订版之前更改了某些内容时，那将是你的错））
2. 做你的构建。
3. 直接提交结果。

可替换地：

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

然后按以下步骤进行：

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

现在有两种可能性：

5a上。你是一个非常可憎的人，通过保持我的方式解决问题。

5b中。你的工作应该工作...阅读日志文件，找出在短时间内你需要将工作复制到文件夹并按下提交的人。跟那位同事说话。同意进一步的行动方案。