DevPath-Problem w. adding subprojects, which are existing in mainline

[JensN.]

Hi @all,

situation is as follows: a subproject (DEF) in a toplevelproject (ABC) has its initial checkpoint 1.1. In this checkpoint it contains nothing, not any subproject and not any member. Later it was becoming a new subproject (named GHI), which is included in checkpoint 1.2, and even later this subproject gets some members. Now the users wanted to branch from checkpont 1.1 and they became a devpath 1.1.1.1, which contains (as expected) also nothing.

But now the users wanted to create a subproject with the same name "GHI" as the one in the mainline, but not a share from the mainline and also not an "add". They made a variant sandbox, and within these sandbox they tried "create subproject". It downst work. Integrity throws some weired exceptions:

mks.frame.app.commands.PreconditionFailedException: mks.frame.app.commands.PreconditionFailedException: The project #/ABC/DEF#b=1.1.1.1#GHI could not be located on the server <serverhostname>:7001: MKS125212: The project file /ABC/DEF/project.pj is not registered as a top level project with the current server.

[...]

Huh?

At the end it seems not to be possible to get a subproject in the devpath with the same name as in the mainline, but independent from the one in the mainline? are there any options to set at the server or the client to prevent Integrity from doing such courious things?

kind regards, Jens

[hsprang]

Hello Jens,

I think I have no answer to your question about settings on the Integrity Server, but what may work is creating a new subproject GHI_2 and then add this subproject as a shared subproject named GHI to your variant. After that you can drop the GHI_2 and you'll only see the shared GHI sub project on your variant which is independent of the original one on the main branch.

Regards

Heike

[JensN.]

Hello Heike,

thanks for your hint, maybe this is a possible solution for some of our users. In the meantime i've also got another way which may help to solve this problem: The subproject GHI at the mainline should be branched manually at its own checkpoint 1.1 before it then should added to the devpath. This just works, but its by far not intuitive. I think this should be offered as an option in the devpath-dialog. Another RfC is coming...

kind regards, Jens

BTW: IMO devpath-handling in all is one of the worst things in Source Integrity in context of usability and user-friendlyness.

[mrump]

Hi Jens,

as far as I remember your final solution (create a dev path for the subproject-(tree) manually and than add it in the dev path. ) is the recommeneded way from the user manual.

From a PTC point of view this is totally logic, but from an end-user perspective it's a Pain in the A.....

I do not understand why the "add/create subproject" command is not as "clever" as the comparable "add member" command: In case you add a member in a devpath that allready has a identically named archive used on the mainline, PTC offers you to "share" the existing archive and to create branch automtically.

That would have been exactly the behaviour i'd expect when creating a subproject on a devpath:

In case a identically named subproject already exists on the mainline, PTC shall create a correctly named devpath for this project automatically and add it to the given project.

Working with devpathes can be quite surprise sometimes.

That's why I'm planning to write a blog about all the traps I've already hit.

[matt_giltaji]

We hit a similar problem often. We have subprojects added in devpaths and then someone will try to create the same suproject in another dev path.

Instead of creating the subproject through the add/create subproject command, what has worked for us is to use the resynchronize change package command to get the creation of the original devpath into the new dev path.

Of course, this only works if you are using change packages and a change package captured the creation/additon of the subproject.

So from your original example, assuming that CP 1234:1 holds the "create subproject GHI" entry, you could resync CP 1234:1 to the variant 1.1.1.1 and this should create GHI on the variant cleanly.

[JensN.]

Hi @all,

@Matthias: i like this idea to write a blog about the traps in integrity! Will it be available for the public or only in your company? Also your sentence about the cleverness of the "add/create subproject"-command isexactly what I was thinking, so we will add an RfC at PTC for this.

@Matt: Thanks for your hint too. And yes, we are using ChangePackages, but they are bound to Integrity-Items, and we have no Item for this usecase.

kond regards, Jens

[jgorsline]

Matthias,

If you're going to write a blog about 'traps' you've run into in Integrity, I'd like to invite you to do it as a Community post here. That way, we in support can keep up with it and hopefully give helpful suggestions and help where we can. Also, it will allow us to enter change requests based on what you and our customers want in future releases of the product. We are always open to any additions or improvements that we can make to improve your Integrity experience.

[mrump]

@Jeremy,

I was planning to use the BLOG functionality here in the community, like I did with 10.2 Upgrade experiences.

It's a little more convinient to edit than the discussion threads.

Maybe you can tell me how to "publish" a BLOG on a community level, because currently it seems like the only way to access a user's blog is via the user's profile.

[jgorsline]

That's currently true. However, if you write the blog I'll get it up here for better visability and discussion.