I am just curious if anyone is using any lock-based approaches to version control for collaborative production of software or other digital assets. It seems like the merge model, exemplified by Git, is ubiquitous to the point that nobody is experimenting with any other workflows.
I think lock-based version control would would very well with trunk-based development. Separate devs branch from mainline, files get locked for everyone else as they are edited, and so it is necessary to work in very tight iterations and merge back to mainline very frequently.
Is anyone working with a lock-based approach to version control, either for personal projects, or in an organisational setting?
Thanks :)
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.
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.
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.
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.
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.