问题标签 [patch]

如果我们需要发布一个不包括已提交的当前开发或当前版本的任何更改的错误补丁，应该如何使该过程更安全并降低开销？

我们目前在一个主要在 Visual Studio 2008 中开发的小型（3 名开发人员）团队中使用 Subversion 进行源代码控制。我们预计该团队可能在明年将 8 名开发人员分组，并且任何先前版本的支持都会变得更加复杂。虽然大多数客户都在使用当前版本，但有些客户落后了。

微软向社区发布的操作系统（通常是基于安全的）补丁和修补程序在我的理解中通常由一系列更新的 DLL 或其他二进制文件组成。

Microsoft 和其他喜欢它的公司如何确保修补程序不会相互冲突？他们是否总是采用累积补丁方法，其中单个修补程序将包含以前修补程序中的所有修补程序？情况似乎并非如此，因为许多修补程序似乎都专注于修复特定问题。如果它们是重点修补程序，它们如何防止一个修补程序破坏另一个修补程序（例如，彼此安装不兼容的 DLL）。

我一直很钦佩微软管理这个过程的能力。我工作的公司规模要小得多，几年前我在处理补丁过程时，我们总是采用累积方法，即单个补丁会立即取代基于该版本的所有先前补丁。这意味着补丁的大小会逐渐变大，直到下一个“官方”版本发布。

管理补丁依赖项有哪些好的做法？

我一直很困惑软件供应商如何发布他们的应用程序或游戏，然后提供一组不同的可执行文件来改变之前构建的行为。这是怎么做到的？原始应用程序和补丁是否必须遵守某种规则？还是补丁会爬入原始可执行文件并更改其程序集信息？这需要二进制文件到字节级别的知识吗？

我们（有时！）必须为我们的产品发布热修复程序，并通过直接重新发布受影响的文件而不是使用新的安装程序来做到这一点。该产品有大量的代码，一些托管代码，一些非托管。

目前，构建工件（exes、dlls）的开发标志需要在热修复中发布。我们希望能够通过将它们与之前的构建进行比较来自动识别它们。一个简单的二进制差异不起作用，因为所有文件的版本号都已更改，因为如果是构建的一部分，则使用新编号标记文件。

是否有任何工具可以进行更智能的比较并决定应包含哪些文件？我们仍然会让开发人员检查列表，这更多是为了捕获开发人员没有想到的文件，而不是相反。

（注意：更改热修复/构建过程不是一个直接的选择，我们是否应该发送单个文件是一个不同的讨论！）

我最近在工作中参与了一个 Java 项目：我们使用 MyEclipse 作为 IDE，使用 Subclipse 进行源代码控制集成。由于我是该项目的新手，因此我目前将我所做的任何更改作为补丁提交，以便其他团队成员更轻松地查看我的更改并决定是否将它们提交到主干。但是，当我使用 Team 菜单中的 Create Patch 选项创建补丁时，生成的补丁包含已更改文件的绝对路径。由于我希望能够将这些补丁通过电子邮件发送给其他团队成员并让他们简单地将补丁应用到他们自己的工作文件夹中，因此我想生成仅包含相对文件路径的补丁（我在 Ubuntu 上运行，目前我的工作副本在我的主文件夹中，所以绝对路径特别烦人）。

有没有办法配置 Eclipse/Subclipse 来做到这一点？我搜索了 Eclipse Preferences 并单击了几次 Create Patch 向导，但我找不到任何看起来可以做到这一点的东西。目前，我正在使用文本编辑器手动编辑补丁文件，以将绝对文件路径转换为相对路径。如果 Subclipse 不能做到这一点，我愿意接受其他建议。

编辑：我知道当您从 Eclipse 中应用补丁时，可以选择忽略文件名路径中的某些段，但我很好奇是否有办法避免这种情况以减少所涉及的步骤数在应用补丁。通过手动编辑路径以使它们相对于项目的根文件夹，最终用户只需确保在根项目文件夹级别应用补丁即可。我想拥有这种简单性，而不必手动编辑补丁文件。

我有一个要修补的设备驱动程序。此设备驱动程序调用 IOLog，我想摆脱日志记录。

如果我用设备驱动程序 (kext) 中的（相应数量的）NOP 替换 CALLL 到 IOLog，内核会崩溃，看起来像一个破碎的堆栈（“Backtrace 终止 - 无效帧指针 0”）。

然而，相同的技术在用户空间中工作得很好（例如，在 OS X 二进制文件中 NOPping NSLogs）。

我在这里想念什么？

有什么方法可以捕获 Linux 上的所有系统调用？我知道的唯一解决方案是使用 LD_PRELOAD à la fakeroot，但这仅适用于动态链接的应用程序。此外，这种方法需要枚举所有系统调用，这是我想避免的。

当您处于版本 1 和版本 2 之间时，您如何维护您的软件？

Patch、Hotfix、Maintenance Release、Service Pack 和其他术语在我看来都是模糊的，根据您与谁交谈而具有不同的定义。

您将发布之间的增量维护工作称为什么？

如何从提交中获取补丁以将其发送给其他开发人员？在以后合并我们的树时，如何最好地避免与此补丁的合并冲突？

如果你知道如何请解释如何在你选择的 VCS 中执行此操作，例如 subversion、git、Mercurial、bzr 等。

场景是：

1. svn cp 或 mv 一些文件
2. 修改那个文件
3. svn diff > mypatch

在其他机器上（相同的工作副本，但没有更改）：

4. 尝试应用 mypatch。
5. 失败 -> 尝试修改不存在的文件。

在这种情况下，如何使 svn diff 产生适用于补丁的补丁，或者干净地应用由 svn diff 产生的补丁？我不能答应。我想保留mergeinfo（因为明显的解决方法是将文件添加为全新的文件，而不连接到前一个文件）。