It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,857
×11,987
×43
×11
×9
×2
×2

question asked: Oct 27 '15, 8:50 a.m.
question was seen: 3,557 times
last updated: Oct 30 '15, 12:15 a.m.

Related questions

How do I effectively use outgoing changesets that contain merge information

0
Evin Robertson (30●3●6) | asked Oct 27 '15, 8:50 a.m.
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.
  •  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

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Oct 30 '15, 12:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
0
permanent link
Ralph Schoon (63.3k●3●36●46) | answered Oct 27 '15, 10:07 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Oct 27 '15, 10:13 a.m.
I am not the most elaborate SCM user. However, here my thoughts.

Before accepting you can (assuming you have auto check in disabled)

  1. 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.
  2. 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
Evin Robertson commented Oct 29 '15, 7:31 a.m.

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.

Your answer

Register or to post 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.