4.0 Exclusive checkout - not seen on other clients

[CodingGorilla]

Is the exclusive lock across all branches, i.e. repository wide?

[manu]

Yep.

[nahuelarjonadev]

On 12/29/2011 at 3:52 PM, psantosl said:

We need exclusive checkout for several uses right now.

You could "easily" simulate it using before-checkout triggers, having some sort of global list, but it takes some time to implement. This is exactly what we want to do.

My goal is to have it up and running before the end of January, but we've really a lot of things on the table right now.

My plan is to modify a little bit the "checkout" operation so that "exclusive checkout" continues making sense even on distributed environments... so, have some sort of "central server" to control "exclusive checkouts"... It will be optional so teams can choose whether they want to work on "checkout mode" or not.

Hello there! Sorry for reviving this really old post, but it was the first that showed up when googling the topic of exclusive checkouts in a distributed environment. Is there a way to make exclusive locks work on distributed environments right now? E.g. something similar to this workflow:

1. I request a Lock and Checkout on a file on my local server.
2. That operation, before running locally, triggers a Lock and Checkout operation on the central server.
3. The central server sends back a response stating if the Lock and Checkout operation on the central repo succeeded.
   1. If it succeeded, then the file is also checked out and locked locally.
   2. If it failed, the user is warned that someone else already has that file locked and the local operation doesn't go through.

Similar functionality would happen for checking in files. Effectively, "local exclusive checkout/checkin" would become a mirror of "server exclusive checkout/checkin".

Motivation for this ask: We are using Plastic Cloud (paid customers), and several of us work on both binaries and text files, binaries rarely being less than 30% of the work. Not being able to easily checkout binaries exclusively is enough of a reason to ditch the distributed workflow entirely, and be forced to use Gluon with a centralized repo workflow. This kind of defeats the purpose of us having switched over from SVN, as one of the (if not THE) biggest reasons we decided to give Plastic a try was to get a distributed workflow for "mergeable" files as a possibility. So, even if this is not officially supported yet, could you hint me about ways to achieve this via some workarounds? Using triggers maybe? How can I kick operations on the central repo from a script or something like that? Thanks for your understading!

Edited June 5, 2021 by nahuelarjonadev
small edits

[calbzam]

Hi,

We have this other thread where we were receiving feedback about distributed/multi-branch locks:

- it's in our roadmap top improve the lock mechanism to support mutiple branches or distributed environments but I'm afraid it's not currently available.

I don't see how triggers would help for this workflow. You could lock an item in the local repo and then run a operation to also lock it in the central server but it won't prevent to lock the same item in a different  local repo of any of your coworkers.

- I'm guessing if you can use one workspace configured for a distributed workflow when you are working with source code (mergeable files) and use a centralized workflow (with Gluon or Plastic GUI) when the task involves locking some binary items.

Your feedback is welcome.

Sorry for the inconveniences,

Carlos.

 

[nahuelarjonadev]

Edit: Moved answer to