Split out a changeset while it is in progress
One answer
You can do this but you'll have to at least create another change set and use a patch. There is no built-in function to choose a hunk to move to another change set. If your change set is completed, you'll have to create two new change sets. The key point is you check-in what you want as one change set and complete that change set. Then you check-in the rest of the code to the second change set. Beware that the second change set will depend on the first one and you cannot deliver the second change set without delivering the first one.
You can also suspend the first change set before checking in your remaining changes to the second change set. This will make the change sets independent of each other. However, if you want to deliver them together or have them in the same configuration at the same time, you will have to merge the changes.
Comments
Hmm that sounds about right; according to RTC's terminology I've already checked in (i.e. committed), but not yet delivered (i.e. pushed), right?
I don't think there's an existing work item describing what you want. Please open an enhancement or go through IBM support to request an RFE so that this can be prioritized for future releases.
I can understand why sometimes this would be nice to do, but it scares me if someone can modify the history of a work item. Currently a completed change set is immutable. There is a request to be able to open it again for modifications. I can see the value because I managed to get myself in situations where I'd wanted to do it. On the other hand what impact would that have e.g. if you look at approved changes and then someone reopens, rips something out and wraps something else in.
Also, what is supposed to be visible in the history to calm down auditors?
If one allows re-opening change sets, each change set effectively becomes a little "mini-stream", i.e. when you accept the change set, you actually accept a particular state of that change set, and if the state of that change set changes, that new state shows up as an "incoming change" in the pending changes view. Similarly, a particular state of a change-set is associated with a work item, and new states of that change-set show up as "incoming changes" to that change set. Updating the work item to point to a different state of a change-set is controlled in the same way that adding/removing a change set to/from a work item.
Thanks for the clarification Geoff. It gets increasingly complex though and I am excited to see how this can be handled in the UI. 8-)
In my initial comment, I was was trying to suggest that I would like to modify a change set which was not yet marked complete—not that I would like to modify a change set which has already been marked as complete.
This working model would, I think, require to be able to accept incomplete change sets into a workspace as well, right? To be able to properly review the change for me at least. In the past that has not been possible. Not sure if there are changes in 4.x.
I don't think you can accept incomplete change sets as-is, but you can accept incomplete change sets into your workspace as a patch. (3.x client, 4.x server.) Our code reviews tend to be sanity checks and a diff read-through rather than functionality testing, so perhaps that how our working models may differ.
Comments
Clement Liu
Apr 08 '13, 12:37 p.m.Is this what you're looking for?
Peter Weller
Apr 09 '13, 5:31 a.m.Almost, but that enhancement doesn't seem to include hunks/changes within a file (i.e. it only covers moving files between changesets).