Skip to main content
R
rslaymaker1-Visitor
1-Visitor
September 27, 2012
Solved

Atomic check ins?

  • September 27, 2012
  • 1 reply
  • 2131 views

Is there a way in MKS SI 2009 to perform atomic checkins?

For example, I'd like to add, drop and edit files and check in all of those changes as a single, atomic repository change action so that others can't resynch, check out (or create devpaths or variant sandboxes) for inconsistent repository contents between the individual actions.

Also, if a long check in fails or pauses partway through, for example due to a "do you want to branch that" dialog, missing file dialog or file I/O error, I'd like none of the preceding actions to go in. This is also to protect others from acting on inconsistent repository contents while I fix the issue.

Obviously, defered actions come close, but are they truly atomic or can partial commits and checkin/checkout race conditions occur? This is aggravated by an occasionally slow VPN-checkins can take minutes at times due to large numbers of files and some large files.

Many thanks,

Barrie

    Best answer by mrump

    Hi Barrie,

    did you try "transactional ChangePackages".

    IMHO That seems like the feature you need.

    Basically it's an "all or nothing"-approach concerning the submission of a ChangePackage.

    Like allways, there are some drawback with this as well:

    Transactional CP affect the option of concurrent locking. That means as long as a member is locked in a transactional ChangePackage it cannot be locked by annother user (not even non-exclusive). This can especially painfull if you use the internal CP review mechanism, that add's even more time to the submit CP process.

    HTH

    1 reply

    M
    mrump16-PearlAnswer
    16-Pearl
    October 2, 2012

    Hi Barrie,

    did you try "transactional ChangePackages".

    IMHO That seems like the feature you need.

    Basically it's an "all or nothing"-approach concerning the submission of a ChangePackage.

    Like allways, there are some drawback with this as well:

    Transactional CP affect the option of concurrent locking. That means as long as a member is locked in a transactional ChangePackage it cannot be locked by annother user (not even non-exclusive). This can especially painfull if you use the internal CP review mechanism, that add's even more time to the submit CP process.

    HTH

      R
      rslaymaker1-VisitorAuthor
      1-Visitor
      October 2, 2012

      Thanks, Mattias, that would be perfect. I see transactional change packages referred to, but not explained or defined (not even in the description of adding a change package), in the 2009 client user's guide, and I see it mentioned in the admin guide. Are they really supported in MKS 2009?

      Either way, I don't think our server was configured that way--is this feature is configured off by default? If so, then I suspect that our admins never changed it to the more robust, but less convenient, setting. I'll check with them.

      Assuming that our server is set to not require them, is there a way for me to create transactional change packages without reconfiguring the server (I don't see any options offered on the Create Change Package dialog--am I looking in the wrong place)?

      We really don't want to force everyone else in our organization to use them... especially with the inconvenience caused to those using the CP review process.

      Thanks,

      Barrie

      M
      mrump16-Pearl
      16-Pearl
      October 2, 2012

      Hi Barrie,

      unfortunately you cannot set the "is transactional" option for each CP individually.

      Transactional CP are a policy that can be set globally or per Source Project in the Integrity Admin GUI (just a the review CP settings)

      HTH

      Matthias

        Terms & ConditionsCookie settingsAccessibility statement