have some trouble using PTC Integrity ... hope it´s due to my beginner status
(0) setup a sandbox
(1) have a binary file member
(2) make working file writable
(3) apply some changes in the sandbox (to the working file)
(4) do a CheckOut to bring the changes under source control
(5) the CheckOut always (regardless of any settings in the UI, e.g. "overwrite working file if changed") overwrites the "local" changes in the sandbox with the content from the server! (similar as Resynchronize command)
If I do the same workflow on a ASCII/Text file, then the CheckOut keeps the local changes in the sandbox, which is absolutely what I expect and want.
To me it seems that Integrity behaves totally different for binary files as for ASCII files.
How can I change the behavior to always keep local changes in the :working file on a CheckOut?
Integrity Version 10, Build 10.5.0.5479
Thanx in advance
Solved! Go to Solution.
I have tested your scenario with a binary PNG file .
When I check out the file I get a warning message box. Please see the attached screen captures.
Please verify your Check Out operation preferences
Follow from the menu File->Preferences->Configuration Management - > Commands -> Check Out
On my computer I have
- an "On conflicts" dropdown list which is set to "Confirm" .
- a checkbox with a question mark "[?] Overwrite working file if changed"
For this reason when I actually perform the Check Out operation I can see in the "Options>>" section.
the "[?] Overwrite working file if changed" checkbox set with a question mark
I assume this is why the PTC Integrity Client asks before overwriting my image.
I´ve already consulted these settings ... w/o success.
I observe different behavior for ASCII and binary files.
On ASCII files,
all these settings work as I expect -- I can "checkout" the member and have the LOCK applied to it, local changes in the sandbox not discarded.
Only the "[?] Overwrite working file if changed" does not open the dialog ... simply does the same as "[ ] Overwrite working file if changed".
On binary files,
the checkout refuses to apply the LOCK to the member whenever I try to keep the local changes in the sandbox (the working file is modified).
Thus I can not use the checkout command when I have already modified the binary file.
Is it a bug or a feature that binary files are treated different compared to ASCII files?
What is the intention of the setting:
Revision to checkout --> Pre-Defined-Revision: Working
I thought this would mean that I "checkout" the current working file, thus keeping potential local changes and apply the LOCK.
But it looks like this setting does the same as when selection "Member".
But we are lucky, there is the "workaround" with the "Lock Member" command as suggested by Thierry which works fine so far.
Still need to figure out on which version the LOCK is applied ... but I hope/guess it will be the correct one
>Only the "[?] Overwrite working file if changed" does not open the dialog ... simply does the same as "[ ] Overwrite working file if changed
Isn't that strange as well ?
>Revision to checkout --> Pre-Defined-Revision: Working
On my computer when I actually perform the Check Out operation, I have
Revision to checkout --> (*) Pre-Defined-Revision: Member option selected in the dropdown list
the defaults on my setup are the same as yours, but I played around a bit to figure out if these setting have some effect.
Isn't that strange as well ?
My current conclusion is to avoid using checkout, instead using the "lock members" command. Until I experience some trouble.
Why: my current project is about c, python, LabView and some office docs .... involving lots of binary files where I do not want to lose my local changes ....
you can control which version you want to lock from the Member History View/Tree (Alt+Enter).
You may want to check-out with no lock before to get for example the head revision as your working revision (si co --gui --nolock).