How can I automate the steps to create a new subproject when propagating a change package for future branches ?
Could you clarify what you mean by that?
I have a powershell script that auto merges changes from one branch to another. But when it tries to merge new subprojects, it gives me an error saying that the files don't exist in the merge that it is trying to merge to. It only happens when the type of action is 'Create Subproject' on a change package. I'm looking for any suggestions on how to propagate changes packages that creates subprojects during the merge process.
Do the subprojects exist in the system before the merge is started? You make have to script a routine that creates a subproject as a destination before adding the contents of other subprojects into it.
Yes, the new subproject is created manually by the user prior to merging. So would I use the si.exe createsubproject command to create the new subproject ?
I have not seen your script, so I this is more of a suggestion, but I think it is sound.
I would say that merging 'new' subprojects would require a container subproject to merge them into. The 'si createsubproject' command would be correct, and the variables you pass it can be used to target the merging subprojects in your script.
si addsubproject allows you to re-add a dropped subproject.
For example, si addsubproject c:/Aurora_Program/bin/Libra/project.pj
si createsubproject creates a subproject on the server in a specified directory, which must be under an existing project specified by the -P project or --project=project options.
For example, si createsubproject --project=c:/Aurora_Program/project.pj c:/Aurora_Program/bin/Libra/project.pj
This command works with Regular and Variant sandboxes, but not with Build sandboxes.
For usage and more information, please see the Source Integrity CLI Guide
if the new subproject has new members with it, do those new members automatically get added during propagation ? also do I have to create the new subproject in the trunk first before propagation ?
I also have the feeling that in case the subproject already exists on the server
si createsubproject does the same than si addsubproject.
It just additionally asks for the location and if it really should add the subproject.
(guess this could have been the motivation for Hectors question)
Could that be true?
In our case, if it's a brand new subproject, it will never exists on the mainline. I have to create it on the mainline first and then I can use either commands. My question is which one would be the better command to use to propagate ? createsubproject or addsubproject ? and do I have to execute the command explicitly or implicitly ? that's one of the errors that keep stopping the project creation during propagation.
Just a little brain storming:
If I should guess what si createsubproject does in case the project already exists in that location
I would say it does the same than
c:\prj_devpath_DP_A>si addsubproject --type=default new_prj/project.pj
If this is true for my taste I would rather use si addsubproject so the srcipt is more speaking.
From CLI Guide 10.4 I would also say that at least devpath "DP_A" must exist in
new_prj/project.pj (which was created in "DP_B") to make this command succeed.
(so there should be no need to create the project in the mainline)
If the parent project is in devpath DP_A than it should do the same than
c:\prj_devpath_DP_A>si addsubproject --variant=DP_A new_prj/project.pj
Depending on which checkpoint of new_prj/project.pj you created DP_A
new_prj/project.pj(DP_A) might be already populated when you add it.
If you intentionally or accidentially created DP_A on checkpoint 1.1 than you will get
an empty subproject.
If starting with an empty subproject will than propagation be smart enough to translate
"add member" to "add member from archive"? Or would that be to smart?
How does propagation handle "add member" in general?
As you can see I'm a propagation noob
my experiences merging devpaths are of manual nature (and with Intergity 10.4).
Anyhow your problem can be seen as a "request for manual interaction" from propagation