My first instinct is to branch normally (using p4 integrate), and then use an IDE or sed script to change the package names. But this makes future integration from the trunk extremely painful.
A:
If you need to change the package names then that's really the best you can do. Integrations probably won't be that bad, though. Just make sure that when you initially re-integrate from your branch that you undo the renames. This will let perforce know that the package statements are "in sync" even though they're different. Merge conflicts on the package statement lines should then be extremely uncommon.
The big annoyance would be if you add new classes later on and then integrate them to the other branch. You'll need to remember to always reintegrate back and undo the package rename.
Laurence Gonsalves
2009-06-09 01:15:52
A:
Future integrations should not be a problem. Perforce will recognize those as changes in the branch, and if you do happen to push a change up from the trunk, it won't bug you about them.
Even in the more common case where you are pushing your changes from the branch back to the trunk, Perforce should only suggest integration the first time. By limiting the integration revision range on later revisions, the package name changes should not be suggested for integration.
erickson
2009-06-09 03:56:56
+1
A:
The way you suggest would work just fine, and you should expect no troubles from Perforce.
However, I can add the following suggestion -
First do the integration followed by commit - and only as a second commit change the actual names.
This would allow seeing the changes in the history much more clearly, not requiring comparison between branches.
If the change requires renaming files, which it probably does -
- You would have the branch in a not-compiling state for a minute there. This is an acceptable trade-off for the visibility you gain.
- You would probably want to create a branch-spec to reflect this rename between the two branches. It would make integrations easier.
Hexagon
2009-06-09 04:25:48