Skip to main content
J
JensN.1-Visitor
1-Visitor
November 6, 2012
Question

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

  • November 6, 2012
  • 1 reply
  • 5319 views

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

    1 reply

    H
    hsprang1-Visitor
    1-Visitor
    November 6, 2012

    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

    J
    JensN.1-VisitorAuthor
    1-Visitor
    November 6, 2012

    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.

    M
    mrump16-Pearl
    16-Pearl
    November 6, 2012

    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.

      Terms & ConditionsCookie settingsAccessibility statement