I suggest you ...

VCM should check to see if any items participating in the session commit have already been changed before the VCM commit is started

Before the start of a vcm commit, vcm should check to see if any files(items) participating in the session commit have already been changed

2 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        This is no longer impacting teams I work with since most have moved over to Git.

        Once a VCM session is created it locks files in the target view that will get modified as part of the merge. Some users who have rights to break a lock sometimes break the lock and modify the file w/o checking why it was locked which I agree is irritating, but when someone later attempts to commit the VCM session they are presented with a message that one of mote files are changed and asks if they want to close or restart the VCM session, neither of which offer them a way to move forward w/o having to redo merges for all those merges that they have already spent time resolving and are not affected bu those modifications in the target view.

        In the above scenario, the VCM session should not only identify the files that got changed (thereby preventing the VCM session from being committed) but also offer the user the option for it to re-compare just those files that got modified so that they can resolve just those merges/conflicts while keeping intact the resolutions that have been done and are not affected.

      Feedback and Knowledge Base