Development path

[abhide-3]

How to create a development path in MKS source integrity. I have created one. But whenever I lock any file on development path, mainline file gets locked too,. So I am not sure if the development path is working correctly.

If the mainline file is getting locked , will it also get updated to next version if I check in in development path. This is something I surely dont want.

Will anyone please provide more insight on creating and using development paths?

[mrump]

A project in PTC just consists of a certain combination of members (==  archive + revision) and potentially subprojects.

Figuratively speaking, this project configuration can be thought of as a file in which the names and versions of all valid archives in the project are recorded. In this respect, subprojects are pointers to other project configuration files rather than to archive revisions.

The project configuration “only” ever contains the applicable pointer for that moment in time, as defined on the PTC server.

To save a project configuration, a checkpoint is created and therefore, in a sense, the project configuration (file) is saved and checked in.

This process is always carried out recursively. Projects are represented in the PTC-GUI as a folder tree; however, they are autonomous in each node of the tree, meaning each subproject is independent and has its own history.

In a similar way to archives, branches of a project configuration – known as development paths – can also be created. This essentially involves creating a copy of the project configuration file, checking it in as a branch, and then developing it further once decoupled from the trunk.

The MAINLINE is only a special name for the Initial ("most left")  development path.

Given that, it is correct and as designed if a lock in development path is shown on the same member  as in the mainline.

A checkin will always create a new revision for an archive. By Default the checkin is combined with the "Update member revision" command.

This  "Update member Revision" will only affect the development path you currently work in, as only this development path's configuration is changed to use this new revision.

All other development pathes of the Project (including the mainline) won't change:

• the new revision of the archive will be available as well, but it won't be used automatically.

There are policies and checkin options that control whether you create a member "branch" for each checkin done on a Dev. path, or you stay on the "trunk" (aka mainline of the archive). This can be used to "indicate" the origin of a new archive's revision.

It is recommended best practise to have the mainline of the project use only the trunks revisions of archives, but it is not mandatory to do so.

I'd recomment to read the Integrity manuals or ask your admin for further help.

HTH MAtthias

[kthierer · Accepted solution]

For a better practical understanding of what Matthias said

I would also suggest an exercise on a dummy project with some subprojects and members.

1.)

Create Development path on a "well defined" project revision.

Definitly a "well defined" project revision is one that is neither head or trunk tip.

The trunk tip (1.1) is just an empty project while the head might not reflect the current

state of the project. If you want to be sure the head reflects the curent state, you must

first checkpoint the project and use the new head.

2.)

Create a variant sandbox with the devlopment path you created.

The root of yout variant sandbox will then look like:

  project.pj(MY_DEVPATH)

3.)

Look at the project history and notice the project branch (eg. 1.2.1.1) that was created.

You can also open the build project (1.2.1.1) from the project history an notice what happened to subprojects.

4.)

Optionally ckeckpoint the project providing a label like MY_DEVPATH_CP0

This will make it easier navigating in complex project history trees later.

BTW: The resulting revision (eg. 1.2.1.2) will be the same resp. have the same member revisions like 1.2.1.1.

In fact if you only look at the member revisions you will have 1.2 == 1.2.1.1 == 1.2.1.2

5.)

Make sure that in the preferences for your Check In command the property "Create Branch if Variant"

is not set to NO (at least asking should be configured).

If you now checkout (or lock) a certain member the member revision will not yet branch.

(this is for version 10.4 but I remember a different behaviour in legacy versions).

The branch will occur the first time when you check in a member from your variant project

and answer the "Create Branch if Variant" with YES.

You may even choose not to branch but then you will see a "New revision available"

difference in your mainline project. (I personally rather dislike such a policy)

6.)

Do other operations on members (dropping, renaming, freezing, update member revision, ..)

and notice the effects or non effects on the mainline project.

HTH Jürgen

[abhide-3]

Thanks !

This was exactly what I looking for

[abhide-3]

Thank you !

[KaelLizak]

Hello Apurva Bhide‌,

Did either Matthias Rump‌'s or Klaus Thierer‌'s answers answer your question?  If so, could you click the Correct Answer button at the bottom of the appropriate post to let us know this resolved your issue?  If not, could you let us know what remains unclear, so that we can try to help you understand this issue better?

Thanks,

Kael