I need to create a mks projects to store XML files. It is important to follow a precise revisioning rule for each single file.
When a new XML file is create it starts with revision 0.1 and then at every modification during development
only the minor number is incremented 0.2, 0.3 and so on. When the XML file is approved and usable
for production the major version number is increased so we will have version 1.0. Again the XML file
can be improved with versions 1.1, 1.2, 1.3 and so on until it is approved and marked as version 2.0.
This is done simply forcing the revision number when a member is added or checked-out/in.
My problem is the following: let's suppose I have a file with the following history 0.1 -> 0.2 -> 0.3
and by mistake or a bug in my application the next revision is 5.0 instead of the desired 1.0.
How can I delete the version 5.0 as it was never created, and go back to the 0.3 in such a way
that I can later create the revision 1.0?
If I drop the member and I add it again as a new archive I am forced to put the versions 0.1, 0.2, 0.3 and 1.0
again to reconstruct the file history and it is highly unefficient. Do you have any idea?
I found partially the solution. If I have the History of a file:
0.1 -> 0.2 -> 0.3 -> 5.1
I can remove the 5.1 from View member History, Delete Revision and resyncnhronize.
Now the working file is 0.3 and the History is:
0.1 -> 0.2 -> 0.3
The problem is that I cannot anymore create a revision 5.1. If I try I get the Error:
Do you know how to solve the issue?
Hello Antonino Battaglia,
PTC Integrity Support strongly recommends against deleting revisions, in part because of this situation, and in part because anything referring to the broken revision will now be orphaned. You literally can't re-use a previously used revision of a member to avoid confusion about object references.
Which release of Integrity are you using?
Edited 2016-04-14EDT1122: Added mention that previously used revision IDs can't be re-used.