This would never work. If someone checked out a file, locked it, and then went on vacation, this would block everyone else. Imagine if some breaking bug was in the checked out file, now you have to find some admin to remove the lock. You could put a timer on the lock, but how would this be different from git?

Perforce does trunk based development and checkouts involve talking to the server (depot). This allows you to see who else has a file checked out, but doesn't block you from editing. I have used Perforce for multiple years in a thousand+ developer org, and have never actually needed to see who else has a file checked out.

When I've worked with Perforce it was quite common to double check who has the file checked out and lock when necessary, especially for content creators. And to sometimes use exclusive checkout on certain file types or directories (though this was thankfully more rare).

Some of the versioned files being modified while working on game data are difficult to manually resolve conflicts in. At best they're a bunch of XML that you can kind of decipher but which contain various UUIDs to different assets and schematics connections which are not intuitive to resolve by hand. At worst they aren't even parse-able by a normal human. Then you have things like versioned animation sandboxes which have to be locked for any changes and submitted from a CI machine, not allowing any content creator to touch them lest they don't have the right source locally to reimport from. Files were even locked while running through a presub process to ensure no conflicts were introduced between presubmit initialization and commit. Users could check them out and work on them, but not submit until the in-flight presub touching those files was done (at which point you just hope that the conflict won't be too painful to resolve).

Having locked files was usually considered a hassle though, and more of a necessity of an imperfect workflow rather than a feature. Having the _option_ to lock was often very useful and practical, but actually running into a locked file when you just want to change an asset configuration or something could be annoying.

Presumably, you would have a mechanism for "stealing" a lock from someone who's on vacation. Their branch would be left in an unmergable state until they re-apply their updates on top of yours.

We still use Perforce as well, for some projects. We also don't use exclusive (locking) checkout and merge problems are resolved the usual way.

I do like to see who else has a file checked out because you can usually also tell which workspace it's checked out to, in our environment that's quite helpful since I can tell which PC it's on.

Microsoft TFS has exclusive checkout and this is exactly what happens. Someone locks a file and forgets about it.

We still use Microsoft Visual Source Safe for some projects :)

We have a main trunk, and a branch for each major version released, upon which we apply fixes and occasionally small feature updates as requested by customers.

We’re a small team, so it works pretty well for us. We’ve worked this way for 15+ years.

This is kind of retro - is there any particular reason you stick with VSS other than maybe the difficulty of migrating the file history to something more modern?

I used VSS myself back in the day, but things like git have a lot more features that make things like branching/merging much easier than fighting VSS.

Out of all the version control systems I've used (SCCS,PVCS,Envy/Developer,VSS,SVN and finally git/github), I found github to be the easiest to use whether building my own stuff or collaborating in larger groups. VSS was barely functional compared to even ancient things like sccs.

Lots of automation and no spare time.

Fair enough.

Isn't Source Safe a discontinued product? I thought support ended for it in 2017?

Yes, we use locking checkout in certain situations but not for traditional source code, more for CAD files or documents. It's a fairly rare situation, though, mostly helpful for non-coders that don't understand the concept of a merge.

Not software development, but most CAD version control systems are lock based. You checkout your model or assembly, lock the parts/drawings/assembly you are working on and that prevents others from working on the same bit. Some allow a level of collaboration where two people can be working on different components within the same assembly at once.

Most of these version control systems are part of a larger software package call a PLM system (Product Lifecycle Management) designed to help manage all aspects of product development from concept through to manufacturing.

https://en.m.wikipedia.org/wiki/Product_lifecycle

I used to work for a firm creating software for handling patient's data in hospitals. Mainly using Xenix, all software source was controlled via the Revision Control System, part of the OS. R.C.S allowed earlier versions of source to be generated easily, when required. All devs using R.C.S accepted it and used it easily, many times each day.

Didn't we had the lock based model when a lot of software development was using svn earlier on?

I also still experience it on Wiki edits, and for office document management systems. My experience there is that it works for a tiny amount of users, but once you start hitting the lock things get painful.

Yep, Subversion was definitely better than "copy of project 2 copy 3 FINAL", but it doesn't compare favourably to git.

Although that said I did used to play a game where a community mod pack was delivered via SVN - you'd simply check out the repo into your mods folder and everything just worked, and updating became trivial. This was a fair while ago before Git LFS was mainstream and SVN had better large file support (as in many files in the hundreds of megabytes per each, not multi-gig assets - this was in the era post dialup but while residential "broadband" speeds were still quite slow).

> exemplified by Git

The predecessors, SVN and CVS, also do not use a locked checkout model. The "C" in CVS is "concurrent": people working at the same time in multiple checked-out sandboxes (of a central repo), picking up changes with "cvs up", which merges.

Nobody in their right mind used version control with central locking in the last 35 years.