RTC：解决流间隙？

Question

我有一个RTC文件（称之为foo.c）我修改并检查了变更集（CS1）以及其他一些更改。然后我再次修改了该文件，并将其与其他更改一起检查到不同的变更集（CS2）。

我现在遇到了一个我希望将CS2传递给流的情况，但是RTC给了我一个错误，即传递它会在流中产生间隙（因为CS1的变化）。我还不想提供所有CS1，因为它包含一些不应该在构建中的更改。在foo.c对CS1的原始改变是对#include的轻微删除，并且不影响任何其他内容。

有没有办法解决这个差距？

我在RTC文档中看到了一些关于应用补丁的内容，但我不明白它的用途。 有没有办法将变更集拆分为多个变更集，这样我就可以只交付一个文件？

Answer 1

自2012年以来的更新（以及提供所有内容并恢复您不想要的内容的原始“解决方法”）：

见this thread：

在RTC 4.0.5中，我们在尝试接受具有间隙的变更集时提供了额外的支持（在尝试向后端口修复时经常遇到）。

在该功能的简短摘要中，当您接受带有间隙的变更集时，您现在可以遵循一次接受一个变更集的间隙工作流，对于包含间隙的变更集，创建一个新的变更集（有助于可追溯性），包含等效的变化。 这意味着用户不必接受变更集'作为补丁'。

与新工作流程相比，将更改集应用为修补程序具有局限性。 RTC 4.0.5 'New & Noteworthy' page总结了此功能。

以下是一些显示此功能的视频：

• Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE
• Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE

这是Locate Change Sets功能：

---

在RTC 5.0中，我们添加了“填补空白”功能，其中填充空白的更改集向用户显示，允许他们接受所有更改集或继续RTC 4.0.5中提供的间隙工作流程。

RTC 5.0 'New & Noteworthy' page总结了这个功能：

填补空白所涉及的类包括（在RTC 5.0中可用）：

client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...) 
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...) 

这两个功能在“Improved Gap Handling for SCM”文章中有详细解释。

---

原始答案（2012）

有没有办法拆分变更集？

我不这么认为，阅读changeset man page：

组件中的文件或文件夹不能是多个活动更改集的一部分。 当活动更改集中包含文件或文件夹时，对其进行的所有更改都将成为该更改集的一部分，无论更改集是否为最新，并且无法将对该文件或文件夹的更改明确签入到新的更改集中，直到包含它的活动更改集已完成。

在CS1和CS2中使用foo.c意味着CS1已经“完成”（本质上是冻结的），尝试拆分它会很糟糕。

补丁解决方案意味着：

• 取消CS1
• 将附加更改添加到foo.c到CS2
• 重做CS1的变化

见“How do I remove a change set from a stream?”

Story 149483是关于增强繁琐的工作流程，并且差距检测正在加强（Enhancement 24822）

---

OP timwoj得出结论：

我最终只是提供了所有这些，然后扭转了我不想要的那个。

Answer 2

问题：CS1改变了foo.c，CS2进一步改变了foo.c.你只想提供CS2，但RTC告诉你会引入差距。

解决方案：从CS2创建补丁并暂停CS1和CS2。然后应用补丁，将其合并到您的工作区并签入更改，这将创建另一个更改集CS3，与CS2相同但不依赖于CS1。您现在可以提供CS3。

交付CS3后，您可以丢弃CS2并恢复CS1，这将要求您与CS3合并。

那么你应该处于CS1在CS3上构建的状态，你可以选择是否在将来交付CS1。