RTC：解决流间隙？(RTC: Resolving stream gaps?)

RTC：解决流间隙？(RTC: Resolving stream gaps?)

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

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

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

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

I have a file in RTC (call it foo.c) that I modified and checked into a changeset (CS1) along with some other changes. I then modified that file again and checked it into a different changeset (CS2) along with other changes.

I've now run into a case where I want to deliver CS2 to a stream, but RTC is giving me an error that delivering that would create a gap in the stream (because of the change in CS1). I don't want to deliver all of CS1 yet, because it contains some changes that shouldn't be in a build yet. The original change to foo.c in CS1 was a minor removal of a #include, and doesn't affect anything else.

Is there any way to resolve that gap?

I see some stuff in the RTC documentation about applying patches, but I don't understand where it's going with that. Is there a way to split a changeset into multiple changesets, which would allow me just to deliver the one file?

最满意答案

有没有办法拆分变更集？

我不这么认为，阅读变更集手册页 ：

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

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

补丁解决方案意味着：

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

请参阅“ 如何从流中删除更改集？ ”

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

---

OP timwoj得出结论：

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

Update since 2012 (and the original "workaround" of delivering everything and reverting what you don't want):

See this thread:

In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes).

In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes. This means users will not have to accept the change sets 'as a patch'.

Applying change sets as a patch has limitations compared to the new workflow. This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page.

Below are some videos which show this feature:

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

That is the Locate Change Sets feature:

---

In RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.

This feature is summarized in the RTC 5.0 'New & Noteworthy' page:

The classes that are involved for filling the gap include (available in RTC 5.0):

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

Both features are explained in detail in the "Improved Gap Handling for SCM" article.

---

Original answer (2012)

Is there a way to split a changeset?

I don't think so, reading the changeset man page:

A file or folder in a component cannot be part of more than one active change set. When a file or folder is included in an active change set, all changes to it become part of that change set whether or not the change set is current, and changes to that file or folder cannot be explicitly checked in to a new change set until the active change set that includes it is completed.

Having foo.c in CS1 and CS2 means CS1 has been "completed" (frozen, in essence), and it would be bad to try and split it.

The patch solution means:

cancelling CS1 adding the additional change to foo.c to CS2 redoing CS1 changes

See "How do I remove a change set from a stream?"

Story 149483 is about enhancing that cumbersome workflow, and the gap detection is being enhanced (Enhancement 24822)

---

The OP timwoj concludes:

I ended up just delivering all of it, then reversing the one that I didn't want.