Skip to main content
S
ssaul15-Moonstone
15-Moonstone
November 18, 2016
Question

Locked revision changes after Resynchronize

  • November 18, 2016
  • 1 reply
  • 2780 views

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

    1 reply

    K
    KaelLizak16-Pearl
    16-Pearl
    November 22, 2016

    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

      S
      ssaul15-MoonstoneAuthor
      15-Moonstone
      November 23, 2016

      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

      K
      khoppe15-Moonstone
      15-Moonstone
      November 23, 2016

      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

      Terms & ConditionsCookie settingsAccessibility statement