Menu
I've submitted for review a change set. Unfortunately i forgot to refresh my sandbox first, so that means I did not include some changes in that set.
So i lost the option to add changes to my change set.
I don't want to discard that change set because it contains important changes. I also don't want to have to deliver 2 change sets, because they contain atomic logic (logic that can't be split).
I'm having a feeling that the "reverse" option would get my change set back into an editable state, but i really have no idea what to do here.
To sum up: i need to make my change set editable again, so that i can merge it with another one.
Anyone know how i would do this?
Thx, you guys rule!
337
Right-click the component and click Show > History. Navigate to the change set that you want to reverse. Right-click it and then click Reverse. This creates a Rational Team Concert source control patch named Reverse: name_of_change_set , which is displayed in the Pending Patches folder in the Pending Changes view.
Procedure. In Pending Changes, go to the component where you want to create the new change set. Right-click the component, select New > Change set.
I don't think you can revert back to a mutable state for your change set, if that change set was "completed" before being submitted for review.
In that case, a "reverse" (ie doing a new changeset cancelling the previous changeset), followed by a new changeset in which you redo your work and re-submit it for review might be the only solution.
However, following this example of code review in RTC, change sets should be ket mutable during the review (for the original programer to check-in new revisions of his files based on the feedback of the reviewers).
102
You should create the new change set.
I say this for two reasons:
1) The aesthetic argument for only having one change set per work item quickly breaks down in practice - it's easy to forget a change, and you may have to make amendments due to bugs or review comments.
2) Having multiple change sets makes your changes easier to understand. Each change set can contain a logical set of changes, so a single work item may have three change sets: "Refactor code", "Update copyrights", and "Changes from review". That way, when someone annotates the files in future, they'll get something at a finer granularity than the initial work item.
Regarding the "atomic logic" argument: it probably isn't an issue unless your team is in the habit of delivering/discarding individual change sets. On the RTC project, we regularly split logically discrete changes across multiple change sets and multiple components.
If you're concerned that you may deliver change sets that logically depend on changes in other components (as I occasionally do), I suggest you chime in on bug 150421. Bug 153907 describes a similar problem, but requires a much more complex solution (making it less likely to be implemented without customer pressure).
44
I runned into the same issue, and decided to create a patch, discard my changes and then create a new changeset.
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
