How to merge mainline changes in development paths ?

[akuruvila]

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

[KaelLizak · Accepted 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

[akuruvila]

Many Thanks Kael.

I'm able to merge the mainline changes to variant sandbox now

Regards,

Arun

[sguo]

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

[KaelLizak]

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

[sguo]

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?

[mrump]

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)

• "Dropped Member" - those where dropped on the mainline: either re-add them in you devpath or remove them from the sandbox using F6
• "Missing Working files" - those where created/added only on the mainline: to fetch them use F6
• "Out of Sync Members" - those where changed/updated on the mainline:
  • assuming you have all you devpath Check-In made in member-branches, you can now easyly identify the Revision you migth want to keep, and those you just want to resync.

2. The "restore Project" command would do almost the same, except that it works for any dev path not only direct children.

HTH

Matthias

[kthierer]

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