Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X
Hi Team,
I have created a development path 2 months before and few changes happened in mainline after that - can i resynchronise my development path with latest mainline changes (or merge the mainline changes in development path) ?
Regards,
Arun
Solved! Go to Solution.
Hello Arun, You can use Resync CP either to migrate changes from any branch to any other branch. In other words, with Resynchronize Change Packages, you can migrate from any development path to any other development path, including the mainline in either of those cases. Regards, Kael
Hello Arun, You can use Resync CP either to migrate changes from any branch to any other branch. In other words, with Resynchronize Change Packages, you can migrate from any development path to any other development path, including the mainline in either of those cases. Regards, Kael
Many Thanks Kael.
I'm able to merge the mainline changes to variant sandbox now
Regards,
Arun
Hello Kael,
Your reply is really helpful to me too. However, I have an additional question: if my mainline had evolved a lot, meaning, it had hundreds of merges from development paths, does that mean I have to manually add hundreds of change packages to my resync list? Is there a better way of doing this? Thanks!
-Shijia
Hello Shijia Guo,
You can merge development paths with one another, which creates a propagation change package. You might specifically want to look at CS206810 and CS125580 specifically, and in general, search here with terms like "merge development path" and "propagation change package".
Regards,
Kael
Hello Kael,
I guess I didn't convey my question clear enough. I looked over the documents you suggested, and it looks the same as I understand. Let me rephrase my question again:
When I want to merge mainline to development path, or merge development path to development path, I need to manually specify which change package(s) to apply, or use a query, which I haven't found a good way to query yet. Also I will just point the "apply change packages" action to a propagation change package. However, there is no way if I just say, merge mainline at checkpoint A to development path at checkpoint B (the benefit of this is that I don't have to search and specify the change packages myself, the system will calculate them). Also after the merge, there will not be a dotted line suggesting the merge content.
Is that correct?
Hello Shijia Guo,
I know your usecase very well and I thnik there are two other Options you might want to consider:
1. If the DevPath is a direct child of the mainline, you could "rebase it".
That means you drop your deveolpment path (while keeping a previously syncronized variant sandbox ) and create a new development-path with the exact same name based on Checkpoint A of the mainline.
This will copy the complete configuration from CP A into your DevPath. You will of course see the the branch lines in the history.
In your Variant sandbox you will now find (using the filters)
2. The "restore Project" command would do almost the same, except that it works for any dev path not only direct children.
HTH
Matthias
If enabled in your viewset can also use the feature "Retarget Sandbox"
to compare devpaths resp variants
In your case I would:
1.) Create a fresh sandbox for mainline
2.) Resync (if populate sandbox was not activated)
3.) Close Sandbox in the gui
4.) Retarget Sandbox to your variant eg. (Context menu of My Sandboxes->Regular)
5.) Open retargeted sandbox (from My Sandboxes->Variants)
6.) Check/Learn if that what youre now seeing is suitable for your needs
Another method could be to add your mainline project as a shared subproject to another project (eg c:\server\mymerges\project.pj)
Than you would have something like c:\server\mymerges\shared_prj1\project.pj as a sub project of c:\server\mymerges\project.pj
(that points to c:\servers\prjs\prj1\project.pj)
In a sandbox that points to c:\server\mymerges\project.pj you can than configure the subproject shared_prj1\project.pj
to whatever variant or build you want (on the fly) without affecting c:\servers\prjs\prj1\project.pj immediatly.
As for the security of handling I would rather recommend the first method.
Jürgen