Changing your check out mode from "Update" to "Concurrent Update" will not affect ASCII or Binary file check outs. Those will work exactly the same as they always have, except they'll get a branch version number instead of a trunk version number.
If your Development state and Production state share the same data view, and you don't want the new trunk version to be visible in the Production state until the package is promoted there, the rules are:
- You cannot check out or check in new trunk versions in the Development state
- You cannot perform Concurrent Merge to bring branches back to the trunk while in the Development state.
Both of those actions would produce a new trunk version in the Development state. Any trunk version that is visible in Development is also visible in Production. So we don't want to do anything that would produce a new trunk version while in the Development State.
You should
- Make your Check Out process in the Development state to be Concurrent Update only and not Update
- Make your Check In process in the Development state to place new items only on the branch
- Move your Concurrent and Interactive merge process out of the Development state and put them in the Merge state
- On your "Promote to Merge" process make sure the "Enforce Package Merge" checkbox is NOT checked
Let me know if this makes sense.
------------------------------
Melinda Skelton
------------------------------
Original Message:
Sent: 09-25-2019 04:18 PM
From: AHMAD NADEEM
Subject: checkout for update
I am not sure why we initially had this "checkout for update" first place. Specially when we want to control Production code after approval process. Our repository contains ASCII and binary codes. Do you think if we remove this process it will impact binary code.
Or any available mode of "check out update" can help not to show trunk in Production before package move there.
Original Message:
Sent: 09-25-2019 02:45 PM
From: AHMAD NADEEM
Subject: checkout for update
Thanks Melinda for the answer, it does make sense. So basically there is no role of "checkout for update" because this create trunk right in the development thats why it is showing in Production due to same view. We should remove the "checkout for update" ? We do not want to see code in the Production without going through full life style. Or is there any "mode" we can enable which can help in our scenario.
Original Message:
Sent: 09-25-2019 02:23 PM
From: Melinda Skelton
Subject: checkout for update
Hello Ahmad,
The type of lifecycle you're shooting for is shown among the default lifecycle templates as the "Production" template. Here's where you can read more about it: Predefinied Lifecycle Templates - Production
The way it will work is that in the Development state you will only check out files for concurrent update "on the branch", and any new items would also be checked in "on the branch". You would then promote the package with the branches un-merged to the Merge state and merge to trunk at that time. In this way the latest trunk version visible in Development is the same as in Production.
Let me know if this makes sense and answers your question.
:)
------------------------------
Melinda Skelton
Original Message:
Sent: 09-25-2019 01:59 PM
From: AHMAD NADEEM
Subject: checkout for update
Most of our Projects have following states.
Development , Merge, System Test, QA and Production
Development and Production share the same view so when developers checkout code they can get the latest and greatest version. That is fine even code is in any other state the new code does not show in the production.
But, if we "checkout for update" and update the code and after checking-in it create trunk version in Development. This create issue because code still in Development and if our automated checkout script run with "hco" it checkout same trunk from Production even actual trunk is in Development. Is there any option we can enable so Production state would not show same trunk until the package/code move to Production.