Vault 4.0 Deny Exclusive Checkouts

ThomasC · Post by **ThomasC** » Mon Jun 04, 2007 8:40 pm

I just looked at Vault 4.0 today. Is there still no way to prevent people from checking out files exclusively?

lbauer · Post by **lbauer** » Mon Jun 04, 2007 8:59 pm

No, this isn't in Vault 4.0. We had one other request for this, so there is a feature request logged for a future release. I'll add your "vote."

ThomasC · Post by **ThomasC** » Mon Jun 04, 2007 9:58 pm

Are you serious? Only one person other than myself made this request? The CVS style checkout is veritably worthless without it. I'm stunned that it even needed to be requested. Think about it. If you want to enforce CVS style check-outs, you can't if users can still request exclusive checkouts via VS and the old API.

This is close to a deal killer for me. I desperately want to move to merge style checkout system but if I cannot enforce it, then Vault looks less viable and a product like Perforce starts to make more sense.

stefvanhooijdonk · Post by **stefvanhooijdonk** » Tue Jun 05, 2007 2:23 am

Not that we have any real problems with this, but I do agree that this should be a repository of server option !

neal007 · Post by **neal007** » Tue Jun 05, 2007 6:14 am

It's not a number of votes that should drive this feature, COMMON SENSE should! I think I am the one that is the "other" that requested this some time ago, it is intuitively obvious why this is needed.

Post by **jclausius** » Tue Jun 05, 2007 8:33 am

A quick note, even with this feature, disallowing exclusive checkouts will never fully go away. Non mergable or binary files will always require exclusive checkouts as a merge of other changes is not possible.

Is there a reason user's are escalating to exclusive locks? Assuming your repository's file extension list is up to date (or the files are marked as mergeable), then all checkout locks should be non-exclusive. Also note, in Edit, Merge, and Commit mode you do not have to necessarily checkout files. Just start editing them within the working folder, and Vault will handle the rest.

ThomasC · Post by **ThomasC** » Tue Jun 05, 2007 8:58 am

Correct me if I'm wrong, but the default API in Visual Studio is the old MSSCCI API. The developer has to consciously change the configuration in their instance of Vault in order to enable Edit-Merge-Commit style checkouts. Is that not correct?

If my goal is to move developers off of exclusive checkouts onto Edit-Merge-Commit style I have no way of forcing them to change. What's worse is that they can revert at any time.

ThomasC · Post by **ThomasC** » Tue Jun 05, 2007 9:02 am

Let me add one more thought, does it not seem obvious that if you are going to provide a feature that lets Admins restrict users to one style of checkout (Require exclusive checkouts) that it makes sense to have a feature that let's Admins restrict users to the other style checkout?

Post by **jclausius** » Tue Jun 05, 2007 9:09 am

ThomasC wrote:Correct me if I'm wrong, but the default API in Visual Studio is the old MSSCCI API. The developer has to consciously change the configuration in their instance of Vault in order to enable Edit-Merge-Commit style checkouts. Is that not correct?

For unbound projects, no. The Vault 4/Fortress 1 installation configures the new VSIP (VS 2005 IDE) client as default. But for projects already bound to previous versions of Vault, Visual Studio will still use the bindings found in the solution / project files.

Here's the scoop. If you're using the MSSCCI IDE client (Vault 3.5.2 and earlier or Vault 4/Fortress 1 VS 2003 Compatible IDE Client), then Microsoft forces a Checkout, Edit, Merge, and Commit model. That is the nature of Microsoft's API.

However, with our new VS 2005 IDE Client for Vault 4/Fortress VS 2005 , then you can choose either Checkout, Edit, Merge, and Commit or Edit, Merge, and Commit.

ThomasC wrote:If my goal is to move developers off of exclusive checkouts onto Edit-Merge-Commit style I have no way of forcing them to change. What's worse is that they can revert at any time.

If you change the bindings to the new VS 2005 IDE client, then all other developers will be switched to the new VS2005 client once they've done a GET of the newly bound solution / project(s). Then it is just a matter of them switching their SCC options to use Edit, Merge, and Commit.

Post by **jclausius** » Tue Jun 05, 2007 9:21 am

ThomasC wrote:Let me add one more thought, does it not seem obvious that if you are going to provide a feature that lets Admins restrict users to one style of checkout (Require exclusive checkouts) that it makes sense to have a feature that let's Admins restrict users to the other style checkout?

The Admin configures the repository to always use exclusive locks or do not enforce exclusive locks. In regards to a setting to not allowing exclusive locks, as stated above, exclusive locks can never be fully eliminated due to binary and non-mergeable files.

FWIW, if exclusive locks are not enforced on the repository and the file is recognized as mergeable, then it is up to the user to decide the lock type. This can be done on the checkout dialogs within the Vault GUI or the Visual Studio IDE for each and every checkout when using Checkout, Edit, Merge, and Commit mode.

If a file is mergeable and exclusive locks are still being applied, then it is most likely the file is not set as mergeable in its properties, or within the repository's mergeable file extension list.

ThomasC · Post by **ThomasC** » Tue Jun 05, 2007 10:42 am

Given what you have said, then I would phrase the requested feature as providing the ability to deny exclusive checkouts on mergeable files. In other words, force users to merge mergeable files.

Post by **jclausius** » Tue Jun 05, 2007 11:15 am

OK. I understand your definition. I'll add this thread to the feature request.

Have you thought about switching over to Edit, Merge, and Commit mode and not bothering with checkout locks?

ThomasC · Post by **ThomasC** » Tue Jun 05, 2007 12:27 pm

I'd love to but the problem is that I have developers with a range of experience in separate locations and they can be difficult to control. ;-> The real bugger is project files. I can somewhat live with exclusive checkouts on individual cs and markup files but allowing developers to exclusively checkout the project file makes life a chore because no one can add files to the project while someone has it checked out exclusively.

neal007 · Post by **neal007** » Tue Jun 05, 2007 12:40 pm

I don't want any of my users checking anything out exclusively, if I have such an option set to deny. I have had problems where another developer loses a day of work because another developer has something checked out exclusively. I try to tell them how to configure SCC but regardless, I check via Vault GUI and they have exclusive checkouts! I would actually like a permission such that a permission group can checkout exclusive, but "regular" users would not have this privilege. Only experienced devs in my organization would be allowed exclusive checkout, or program managers, etc.

SourceGear Support

Vault 4.0 Deny Exclusive Checkouts

Vault 4.0 Deny Exclusive Checkouts

I second that motion