Locked revision changes after Resynchronize

[ssaul]

Hi all,

we just observed a strange behaviour in Integrity Source 10.5:

When checking out an older non-member-revision (working file refers to that older revision) and then performing a resynchronize, the working file is replaced with the member revision (okay) AND the lock is changed to the member revision.

This does not seem to be okay.

Is this already known and possibly corrected in > 10.5?

Regards, Stephan

[KaelLizak]

Hi Stephan Saul‌,

What's the use case you're thinking of, in which you'd want to keep the lock on an old non-member revision?  Why do you feel it doesn't make sense to change the lock to the member revision from an old revision?  After all, that is what will lead to where the next revision is stored when it's checked in, right?

Regards,
Kael

[ssaul]

Hi Kael Lizak,

just to mention: I already found that the behaviour is "as designed" - In the 10.5 documentation, I found

"If the revision that your working file is based on is locked by you, your lock is automatically moved to the member revision before the resync

proceeds. If another user already has an exclusive lock on the member revision, you are prompted to downgrade your lock"

Our use case is the following:

A user checked out old revisions to compare them to files that were not under the version control. He did it with lock just because this is much easier. He also did this with exclusive lock because the files contained also binaries.

After compare, he did a resynchronize to get the actual versions again, not recognizing that the lock moved (because it was a bunch of files).

Other remote users in another time zone could not check in because of the exclusive lock of the member revisions and could not call the user who was already gone for the day, thus delaying work.

I know that this was a rare case with some faults on the user's side, but anyways, it would be good to get at least get a msgbox for confirmation - as we get for many other situations to avoid user faults.

Regards,

Stephan

[khoppe]

Stephan Saul schrieb:

(..)

Other remote users in another time zone could not check in because of the exclusive lock of the member revisions and could not call the user who was already gone for the day, thus delaying work.

(..)

Hi Stephan,

Delay is not necessary cause at least a key user in same time zone should have possibility to downgrade moved exclusive locks that work can be proceeded without delay.  But you are right, the "move lock" activity is surprising as a follow-up of a synchronisation, and I'm interested of the use case PTC Program Management had in mind to order this change.

Dear Kael Lizak‌,

is there any chance that you can find out?

Best regards,

Klaus

[ssaul]

Klaus Hoppe schrieb:

Dear Kael Lizak,

is there any chance that you can find out?

Best regards,

Klaus

Kael Lizak‌:Any news on this?

[kthierer]

This is already true for Version 10.4.

So there is also an additional archeological aspect of when this "change" did happen

If I would guess for the motivation I would say it is based on the usability assumptions:

a.) If a user has a lock in a members archive he wants to work on it.

b.) If a users resynchronizes having a lock than he still wants to work on that member, but he doesnt

want to branch (anymore).

For the most use cases I find this behaviour somehow user friendly (except that trap with the unintended exclusive lock).

I think the main problem here is that checking out non member revision is mainly designed for a planned branch.

For good reasons locking is also encouraged for checking out.

For such "archeological" tasks as comparing revisions to other local files than the working

file checking out non member revisions is a poor tool.

Support for exporting archives to multiple files (1.1@App.exe, 1.2@App.exe...) would be way better.

For non binary files this would also offer the possiblity to search for keywords across revisions.

For this specific problem a special "check out (NOLOCK)" in the member history context menu could at least help to avoid the locking problem.

BTW:

For a workflow without user interaction regarding synchronisation and lock handling I would prefer

the default behavior to be rather something like:

    Release the lock if sychronisation would change member resp. working revision

Leaving the lock on a non member revision might also be a bad surpprise.

(eg. I guess it could encourage unwanted branches)

     Juergen