How do I effectively use outgoing changesets that contain merge information
If I check in my changes (creating outgoing change sets) then accept other people's changes, my outgoing change sets are polluted with the merge information and I can't work with them as well.
A co-worker suggested always completing change sets before accepting any changes to keep the merges separate from my own work. I haven't tried this yet, and completed change sets are difficult to work with. Is this the intended work flow?
- I can't undo changes from them (it tells me I have to unload/reload instead)
- If I have two outgoing change sets, I can't have changes to the same file in both change sets (svn changelist has the same restriction)
- If I have two outgoing change sets and they contain merges (from accepting changes), I can't deliver one of the change sets by itself; I have to deliver both simultaneously. I also can't suspend one of the change sets. Errors are:
"Delivery for component xxx failed as it would create conflicts in the stream. As you do not have any incoming change sets for this component, you should consider delivering all of the outgoing changes"
"unable to suspend this change set because doing so would create a conflict"In git, I could do a rebase to forget that my changes are based on merges. In svn, this is the default for "update" merges. Is this possible in RTC?
A co-worker suggested always completing change sets before accepting any changes to keep the merges separate from my own work. I haven't tried this yet, and completed change sets are difficult to work with. Is this the intended work flow?
2 answers
Your co-worker is correct (as is Ralph's answer #2). You should complete all of your change sets before accepting any conflicting change sets. This will ensure that all "merge" change sets will be independent of your change sets. I would definitely *not* try to use the patching approach that you describe in your response to Ralph's answer ... that will not help.
I am not the most elaborate SCM user. However, here my thoughts.
Before accepting you can (assuming you have auto check in disabled)
Before accepting you can (assuming you have auto check in disabled)
-
Suspend your change sets. This will remove the changes from the stream and avoid getting merge information in them. If you resume them later, after accepting the changes from the stream, you will have to merge however, if there are conflicts and then the merge information will be created locally, as far as I am aware. You can check those changes into a change set, one for each component. If you have open change sets, changes will go into them. You can have one open change set on a component that is active. You can delay check in, but if you check in and there is a change set active and not completed, the change wil go in there.
- Complete the change sets. In this case, when accepting, any merges will go into their own change set. However, if a new change set contains changes to a file changed in your completed change sets there will be a dependency on these change sets and you can not deliver on without the other.
You can not reopen completed change sets.
It is kind of designed that way too, because you should not be able to delete gaps on the stream.
Comments
I tried suspending my change sets before accepting, but like you said, when I resume the change sets, they are merged, and corrupted with the merge information. So that doesn't help me.
Next I'll try creating patches from my change sets, unload/reload my workspace and re-applying my patches.