roadrunner

Thanks - sounds like 98% coverage with the first implementation.

The lock.conf sounds like a good option - similar to SVN config file with [auto-props] per extension with the addition of setting a particular repo server as the single lock server. Is there a way to manually select a file for locking without editing the lock.conf file? (Using the current server as the default lock server)

Is exclusive checkout near completion?

Exclusive use is desired for both Binary and Text files. Binary files such as graphical resources, and some text files. Most everything can be merged later, but there are times where it's desirable to lock a file from shared use in the shared repo. Some files are simply more painful to merge than others...if you know that ahead of time, lock it. Also, some sections might be in for a big refactor (15+ year old legacy codebase) If you plan on a refactoring a few units, it's best to lock those to prevent merging issues. It simply puts a tool in the developers hands to let them decide when a lock will save future headache. Community Edition user.

It's a blocking issue to me.... can't switch over without it. Any idea on timeframe? Now that I've been using 4.0, I really don't want to use 3 just for this feature. We'll have to use SVN instead of Plastic. (Hopefully if I make you cringe, it'll up the priority level.)

In version 4.0.237.2, the GUI has an option to Checkout and another to Checkout Exclusive. In either case, other clients cannot see this checkout status when connected to the same shared repository. I'm assuming this is a bug as there's no other reason for Checkout Exclusive is there? Is there a planned fix coming for this soon? This seems to be the case even if the revision type is set to Binary (on a .JPG file for example)