Merging between streams and refactoring.
d s (71●7●3)
| asked Nov 23 '10, 9:58 p.m.
edited Oct 13 '17, 3:12 p.m. by David Lafreniere (4.8k●7) As mentioned before, in svn our code is organized as described here
|
Accepted answer
In RTC, if the changes are within the same component and both the source and target folders are loaded, the merge should be fairly straight. RTC uses item IDs to identify the items to be merged so there path in the source and target are not as important as they are with SVN.
What I would suggest is to try out your scenario with RTC to see what happens. This should give you a better feel for how it is handled in RTC. David Lafreniere selected this answer as the correct answer
|
One other answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 24 '10, 1:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
First a question: If you are going to continue to have an
importantthing/src/Foo.cpp, then why did you move it to a deprecated folder and create a "new" importantthing/src/Foo.cpp? That will confuse any SCM system you use, since it has no way of automatically knowing that changes to the "deprecated" Foo.cpp should be applied to the "new" Foo.cpp. But assuming there is a good reason for doing so, one thing you can try in RTC would be to create a "patch" from the change-set you made in the release branch, and then "apply" that patch to the trunk. Patches give you the ability to "retarget" the patch, which should allow you apply it to the new Foo.cpp. Caveat: I haven't tried this myself, so this is not a theory I have attempted to apply in practice (:-). Cheers, Geoff On 11/23/2010 10:08 PM, dsmall wrote: As mentioned before, in svn our code is organized as described here Comments First a question: If you are going to continue to have an
|
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.