Split out a changeset while it is in progress
Hey all,
I'm working on some diseparate changes within the same file, but I failed at marking the first changeset as completed. Now I am unable to move individual changes (as opposed to files or folders) between changesets. Has this been implemented? —if not, is it a planned feature, and what is the best way to do it as things stand? (I'm assuming that I'd have to create a patch and do some partial merges back into my workspace—making sure that I mark any changesets as incomplete.)
I think the function I'm looking for is similar to git add -p. (If you're unaware of this command, check out this pair of screencasts or this blog post if you would rather not end up browsing YouTube inadvertently.)
Cheers,
Peter
|
One answer
The blog post seems to imply that the similar function you want is before committing to choose what you want to commit. In your example, it sounds like you've already committed and want to split the changes in a file to be in separate change sets.
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 figured that creating another change set and using patches would be the way to go. It would be good if RTC had the ability to move changes between changesets. Something similar to git reset HEAD^—the RTC equivalent to un-checking-in changes, which I'm not sure is possible—and then git add -p would be neat. Or perhaps there's a better way? In the Eclipse UI, would it be possible to overload the right-click menu in the compare editor in order to add a "move to change set" function? Is that something you guys think you would consider?
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.
Ralph Schoon
commented Apr 09 '13, 10:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Geoffrey Clemm
commented Apr 09 '13, 7:36 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Having said that, I'm not the biggest fan of the way that RTC marks a changeset as immutable once the developer's marked it as complete; I'm not sure if this is a flaw in which the way my team works, but we often attach uncompleted changesets to work items when asking for reviews, so that we can change them based on the comments (the end result is a much cleaner history—otherwise we'd have a whole bunch of change sets with descriptions such as "had a vim fail, change tabs to spaces after review"). I'd much prefer to see a changeset made immutable once it has been delivered to a stream, but that's just my two cents.
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.
showing 5 of 8
show 3 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Is this what you're looking for?
Almost, but that enhancement doesn't seem to include hunks/changes within a file (i.e. it only covers moving files between changesets).