Marc,
I think you need to warn your users against the two methods that you quoted to "fix "the sync issue:
- the use of the SYNC method
- the retrieve delete add back method.
Both methods, if used without any other form of intelligence will cause a change to be backed out.
Let's talk about the causes of SYNC (repeat what Joe and Ollivier explained) and explain why both methods need to be handled with extreme caution.
A SYNC condition occurs when an element's delta versions do not have a common timestamp with the last (current) time stamp with the same element up the map. There are a few simple scenarios which can create a sync condition (consider the map STG1 - STG2 - STG3 - STG4):
Scenario #1
- A new element gets added to STG1, then an element with the same name type sys/sbs get added to STG3 and moved to STG4. In this case the element in STG1 has no common delta level with the element in STG4 so when moving the element in STG1, or when validating the element a SYNC condition gets detected (SMGR116).
Scenario #2
- An element is retrieved by two users from STG4 and added back with changes into STG1 in different subsystems, both mapping to the element in STG4.
Both elements are in sync because during the add back (or the QE EDIT operation) the last delta level at STG4 got fetched back. You'll see that the elements have 2 delta levels, the oldest being the one from STG4 (the fetched level) the newest being the change level. When you run a VALIDATE on either of the elements it will result in RC0, both are synchronized with the next element up the map.
Now one of the two updated elements gets promoted to STG2, then STG3 then STG4.
If you run VALIDATE on the remaining element in STG1, you will get a SYNC error SMGR116 because the element in STG1 does not have a matching delta level with the most current level in STG4
Scenario #3 (Joe Bigini's):
An element exists in STG4, it gets retrieved, changed and added back, moved up to STG3.
Then the element in STG3 gets retrieved and changed and added back to STG1.
all the elements are aligned. STG4 has the latest level, STG3 has a common delta level with the one in STG4 and a new level, while the element in STG1 has a common level with the element in STG3 and its own new level.
VALIDATE actions against each of the elements would not find any SYNC errors.
Not the element in STG3 is found to be in error (change not needed after all- Scenario 3a, or change needs to be improved Scenario 3b)
=3a=
The element in STG3 gets deleted as the change is not needed.
Now the element in STG1 is no longer connected to the last delta level in STG4 so VALIDATE will correctly report SMGR116
=3b=
The element in STG3 gets updated once more, creating another delta level.
VALIDATE of the element in STG3 will tell you it is synchronized, but a VALIDATE of the element in STG1 will fail, as there is no connection between any level in STG1 and the latest (current) delta level in STG3. (this is very similar to scenario-2).
---------------------------
These are the most common scenarios for sync errors. You can mix the TRANSFER action in or do the same with Quick-Edit, it does not really matter. The current level (last level) at the next higher location in the map must match with a source level.
---------------------------
So what does the SYNC option do and why does it need to be used with extreme care:
The SYNC option tells Endevor that the user knows what he is doing (...) and that the current source version is the correct one
In scenarios #1, #2 and #3b option SYNC will replace what's in STG4 and delete all ithe changes that were made previously. The simplest illustration can be made using scenario#2. using SYNC here would simply backout the parallel change that got to STG4 earlier.
Only in scenario #3a would the SYNC option be harmless, where the user would not corrupt any existing changes but acknowledge the fact that his element is good but not synchornized, although in this case using SYNC would cause the retention of a delta level (the one that existed in STG3) that may have no use and might in the future confuse your users.
Now let's talk about RETRIEVE, DELETE, ADD BACK.
Here too, only in scenario #3a this would be the correct solution. For this scenario it would accomplish exactly what was needed. When the add back gets done, the last level of the element in STG4 gets fetched back and the elements are now in sync, leaving no trace of the deleted element in STG3.
For the other scenarios on the other hand, RETRIEVE, DELETE and ADD BACK would have the same effect as using SYNC with one minor difference.
When adding back, Endevor fetches the last level of the element in STG4 and from then on the elements are synchronized, but as with the SYNC option, the element that was added back does not contain the changes that were made previously in STG4 and thus it will undo them.
The only correct solutionis to retrieve the element from STG4, merge the changes of STG1with the ones from STG4 and then RETRIEVE, DELETE, ADD BACK, or simply add back and use the SYNC option to tell Endevor that you know what you're doing.
The merging process is greatly simplified when using Endevor's PDM function but with ot without PDM, the programmer and in the end the approvers need to validate that in case of SYNC problems nobody accidentally removed any changes that were previously made.
-------------------------------
So tell your users to remember well that SYNC is a sledgehammer approach: using SYNC the programmer will basically say that his source is the best and he does not care what changes were made before him. SYNC will push this version of the element through to STG4 and nothing will stop it.
In most shops that I know of, the use of SYNC is very much restricted and under for good reasons under constant scrutiny.
The SYNC trace that Ollivier mentioned is a tool for administrators to understand why some more complex sync errors are indeed sync errors.
If you think that a reported sync error is not an error, run the trace and if you still think Endevor is not detecting the sync error correctly then we invite you to contact Technical Support.
Avoiding SYNC problems is a very good way to avoid these complexities, but as parallel development has become the norm, we have to live with its constraints and educate our users and avoid them shooting themselves in the foot.
Regards,
Jan van Kan