Hello Gerald,

That's actually not an easy thing to answer, but let me try to give you an idea.

A Version Manager workspace can viewed as a transparency sheet that is laid on top of the project and file view in the GUI, allowing you to change certain properties, which are shown from the (right-click ->) Properties dialog, on the Workspace Setting tab:

Project:

Workfile location

Default Version (label)

Branch Version (label)

Base Version (label)

Default Promotion Group

File:

Workfile location

Changes made within a workspace only affect that workspace, with one exception:

Files and Project inherit from both the parent workspace and from the parent project until a property has been (re)defined in a workspace. Once it is defined, that property will be used by all files and subprojects while the workspace is selected, until it is changed again in deeper nested project or on a file.

The most common use is for someone to define a workspace (private or public) and then change the workfile location at the PDB root. Normally projects have a relative workfile definition, meaning they just add to the path of the parent project. Because of this you can change the checkout / get location for the entire PDB, just by changing the workspace. Helpful for certain processes.

If this sounds very unclear let me know and I'll try to elaborate :-)

The promotion model can be viewed like a specialized set of version labels which each version label being linked to a parent as defined in the promotion model. Whenever you select promote on the group "label", it gets renamed into the parent label.

You can use this concept to identify the state (stage) of a revision. Imagine the following very simplistic promotion model:

Development -> Ready for QA -> QA -> Ready for Production -> Production.

When a developer is done with a given file (stage Development) he can click promote and the group moves up a level to "Ready for QA". The QA manager can now promote from "Ready for QA" into "QA", accepting the newly updated file and run tests after performing a get on all files at the "QA" stage or higher (meaning an unchanged file without the "QA" group associated with it would be fetched using the revision that is associated with group "Ready for Production" or "Production", which is something VM can do automatically by performing a Get on a promotion group).

Once QA has accepted the changes, the file gets promoted again to "Ready for Production". Now the person in charge of production data can promote files at this stage into "Production" and perform a get on this group, updating the files in production.

Promotion groups are generally volatile in that they describe the stage of a revision in a file. You would still assign permanent version labels to be able to go back in time and find out which revision would be associated with "Product Release 1.0". Such labels you could create once the files were promoted to "Production", by assigning a label to all revisions in files that are associated with this promotion group.

Promotion groups can be used to change the security model that Version Manager uses, meaning you can prevent someone in Development from promotion into Production by limiting at what stage in the promotion model developers can promote. Explaining this in detail will take some time, so I'm just posting it here as a note.

Using promotion groups can make simultaneous development on different revisions in an archive (branches) a bit more complicated, as each revision being checked out will need its own unique lowest level promotion group. If you need this you will need to have multiple lowest levels groups. A possible model could include the lowest level "Bugfix", so that group and "Development" could be associated with different revisions.

Hope this wasn't too overwhelming. If you need me to elaborate on anything, please let me know.

Kind regards,

- Richard.

Thanks Richard,

I really appreciate the information you Share with us.

Based on your comment it will very helpfull for us use a Promotion Model.

I was reviewing our requirements and I think our promotion Model will be something like this (I think this is the most general case in many enviroments):



My question is if We can apply some controls in some cases, for Example in our environment When a developer block a file with the check out operation and selects the stage Development we need to maintain the file blocked while the file has not passed the production state, after the file is promoted from the production stage the file will be unblocked.

But if we need to apply an urgent change. We select BugFixes, so the file needs to be unblocked.

How Do I manage these type of controls? Or Is there another way to implements this type of controls.

Best Regards,

Hello Gerald,

Could you please elaborate on what you mean by blocking the file? Version Manager does not feature the ability to prevent everyone from making a change to a file based on the stage of a promotion group. You can control who can promote or perform certain operations, but you cannot prevent a developer from checking out a revision and continue development.There generally is no need for that, though, since a developer is not able to change the previously checked in revision.

Which issue are you trying to resolve or prevent from happening?

Thanks in advance for your reply.

Kind regards,

- Richard.

Hi Richard,

Sorry for the delay in my response,

What I was trying to do is restric the operation "Promote".

In our enviroment when a user from the Developer Group check out a file, He can only select the Development stage, only a specific part of users from the developers group can select the BugFixes option, Sometime this is a simple requirement (Change the color of a form, etc) that can be fixed quickly.

I found the option restrict by promotion group which is ok for us, so I restricted the Developer Group only for the Development Stage, and after We created a New Group called SOAP and We restricted it to "BugFixes" and "Development".

We restricted the other groups based on the Stage ("QA", "Production").

But I have some doubts about how Can I managed an specific situation,

for Example We have the next promotion model:



In the committe we review the package and if everything is okay it'll pass to production.

My question is If we found a Bug in "QA" We need to return the package to Development, but It only can be performed it by the administrator, because He has all privileges, my question if We can restric the promote operation for the QA group, They only can promote to the next level(Committe) or change the promotion group to development or BugFixes, not to Production, is there any way for do that?

And Finally What is the best to manage the rollback operation in PVCS VM based on this scenario, using Version Labels, Promotion Groups?

Thats are some controls that we need to apply, but If There is a best practice that we can apply we are open to hear your suggestions.

I Hope my questions aren't too overwhelming.

Thanks for share your experience with us.

Best Regards,

Hello Gerald,

Sorry for the delay in my response as well :-) I was unavailable for a few weeks.

For the QA group you could restrict their promotion to just the next level (by only allowing the to promote if the group is "QA"). The "demote" operation is more problematic in that you cannot presently restrict the assignment of a promotion group based on the target group. That's something we could consider changing in the product, so we could submit an enhancement request if you are interested in doing that. (Kindly submit a support case if you do).

You could potentially write an application that does the demotion for you (as a different user with sufficient privileges) and have users call that from the toolbar, but that solution may be overly complicated, unless you have a lot of demote requests that are overwhelming the VM admin. If not, having the admin perform this task is the next best thing.

All you really have to do it remove the QA group and tell the developer to fix the problem.If you trust your QA team to not remove the Production group, you could grant them both the Promote To The Next Promotion Group privilege (into Production) and the Delete Promotion Group privilege (to demote back to Dev). Developers performing a checkout to fix the problem would automatically assign a lowest level group.

You could potentially have QA apply a label to the bad revision to help developers find it (but they would have to remove it when done!), or have a designated "Returned from QA" lowest level group which you could then both find and which would promote back up to QA through the regular promotion process.

Hope this help you along. If you have any more question, just let me know.

Kind regards,

- Richard.

Hey I have one of the most popular and fantastic happy wheels free online game which you can without spending any amount it is totally free of cost you can play it without any download and registration.