6

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!

vlad-ardelean
  • 7,480
  • 15
  • 80
  • 124
  • I ran into a similar problem. I set a change set to complete (not sure why I did that) and then I tried to deliver it. But then the Team Advisor blocked the delivery because one file was missing a required comment header. At this point I was stuck, I couldn't change the file because the change set was complete and I couldn't deliver the change set. I fixed it by overriding the comment rule and then I added the comment in another change set. This seems like a rather bad trap, like getting caught in a dead end in a video game and having to reset the game. – Mike Kucera Jun 27 '12 at 17:59

3 Answers3

7

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).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
4

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).

Erigami
  • 804
  • 1
  • 8
  • 20
1

I runned into the same issue, and decided to create a patch, discard my changes and then create a new changeset.

seber
  • 11
  • 2