如何使用不同的java包名称创建perforce分支？
我的第一反应是正常分支（使用 p4Integrate），然后使用 IDE 或 sed 脚本更改包名称。 但这使得未来从主干的集成变得极其痛苦。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您需要更改包名称，那么这确实是您能做的最好的事情。 不过，集成可能不会那么糟糕。 只需确保当您最初从分支重新集成时撤消重命名即可。 这将使 perforce 知道包语句是“同步的”，即使它们是不同的。 包语句行上的合并冲突应该非常罕见。
最大的烦恼是如果您稍后添加新类然后将它们集成到另一个分支。 您需要记住始终重新集成并撤消包重命名。
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.
未来的集成应该不成问题。 Perforce 会将这些更改识别为分支中的更改，并且如果您碰巧从主干上推更改，它不会因为它们而困扰您。
即使在更常见的情况下，您将更改从分支推送回主干，Perforce 也应该只在第一次建议集成。 通过限制后续修订版的集成修订版范围，不应建议集成时更改包名称。
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.
您建议的方式会很好地工作，并且您应该不会遇到 Perforce 的麻烦。
不过，我可以添加以下建议 -
首先进行集成，然后提交 - 并且仅在第二次提交时更改实际名称。
这将允许更清楚地看到历史的变化，而不需要在分支之间进行比较。
如果更改需要重命名文件（它可能会这样做），那么
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 -