Merging between streams and refactoring.
As mentioned before, in svn our code is organized as described here
http://jazz.net/forums/viewtopic.php?t=13572&highlight=
One of the things that we see happening in our group is :
1.) release branch is made from trunk
2.) directory structure on trunk branch is re-organized
3.) a fix is made on the release branch
When this happens merging the fixes forward from the release branch to
the trunk is not trivial but not impossible either.
As an example, so that the directory importantthing/src was moved to
deprecated/importantthing/src and that the directory 'src' contains a file
Foo.cpp that had a fix put into on release branch.
To merge this forward we would
1.) Create a story folder from the trunk. ( Say merge_forward_fix_x )
2.) Check out the story
3.) Right click on deprecated/importantthing/src and select merge
4.) Select 'merge two different trees'
5.) Select the as the start point release/start/importantthing/src and
select as the end point release/trunk/importantthing/src
The above steps will merge all the changes that occurred in
importantthing/src into the trunk even though importantthing has been moved into the deprecated folder.
How would I do something like this in RTC?
Accepted answer
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.
One other answer
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
http://jazz.net/forums/viewtopic.php?t=13572&highlight=
One of the things that we see happening in our group is :
1.) release branch is made from trunk
2.) directory structure on trunk branch is re-organized
3.) a fix is made on the release branch
When this happens merging the fixes forward from the release branch
to
the trunk is not trivial but not impossible either.
As an example, so that the directory importantthing/src was moved to
deprecated/importantthing/src and that the directory 'src' contains a
file
Foo.cpp that had a fix put into on release branch.
To merge this forward we would
1.) Create a story folder from the trunk. ( Say merge_forward_fix_x )
2.) Check out the story
3.) Right click on deprecated/importantthing/src and select merge
4.) Select 'merge two different trees'
5.) Select the as the start point release/start/importantthing/src and
select as the end point release/trunk/importantthing/src
The above steps will merge all the changes that occurred in
importantthing/src into the trunk even though importantthing has been
moved into the deprecated folder.
How would I do something like this in RTC?
Comments
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?
You misunderstand what I am saying.
In the release branch, that is the branch where fixes to the release will be put, the file exists as importantthing/src/Foo.cpp.
In the trunk, that is the branch where development on the next release are happening, the file has been moved to deprecated/importantthing/src/Foo.cpp as part of some refactoring effort.
In otherwords I said nothing about there being a new Foo.cpp in the trunk.
I wouldn't expect subversion to get confused since it knows that I moved the file. However it does and and therefore I have to go through the steps I outlined.
I don't believe a patch is what I want because the checkin comments from the original change author will be lost. That is in subversion, if I use the steps I mentioned, then when I use either the log command or the blame command with the --use-merge-history option then I will see the details from the change when it was made on the release branch.