The locking people are talking about isn't locking for a commit
What happens in many proprietary systems, and in subversion if you choose, is that you need a lock to be "authorised" to edit a file, not to commit the change. The procedure looks like:
1 The lockable files start off read-only
2. You _tell the VCS_ that you want to work on file X
2.1 The VCS contacts a central server, asking for a lock on file X
2.2 If that's granted file X is set read-write
2.3 Optionally your program for working on file X is started automatically
3. You do some work, maybe over the course of hours or even days
4. You save and check in the new file X, optionally releasing the lock
The VCS can't strictly _enforce_ the locking rule, of course you could copy file X, or set it read-write manually, then start working on it, and only try to take the lock a day later. But, when you complain to your boss that someone changed file X after you'd started work on it, of course he won't have much sympathy.
The locking model has lots of problems, but some people have convincing arguments for why its appropriate to their problem. The only options for Git are (1) not appealing to those users (2) persuading them all that they're wrong or (3) offering some weird hybrid mode where there can be a central locking server for a subset of files. If you accept that (1) could be the right option, then the continued existence of Subversion is justified for those users already.
Posted Apr 8, 2010 20:56 UTC (Thu) by vonbrand (subscriber, #4458)
[Link]
In centralized systems (especially those that don't handle merges decently) this is really the only way to work, true. (RCS works this way, for example). But with decentralized systems with reasonable branching and merging this isn't required. And locking a file doesn't really make sense in a decentralized system (there is no single "file" to lock!), so it is left out of the tool. If the workflow requires some sort of "don't touch some file(s) for a while" synchronization, it has to be handled outside.
I believe this requirement's importance is way overblown. How many projects do you work on, where it is really a requirement (not an artifact of shortcommings in integrating changes by the tool)?
Subversion considered obsolete
Posted Apr 8, 2010 21:56 UTC (Thu) by foom (subscriber, #14868)
[Link]
Subversion's locking is purely a workflow management tool: it *is* simply a way to say "don't touch this file for a while".
Being a distributed VCS doesn't make this workflow management tool any less necessary. And it's convenient to have it integrated with the VCS so that "status" shows the status, and "commit" checks and releases the locks, and so on.
I wish I didn't have to keep defending subversion: git is really nice. But come on people, just be honest about what it can't do, and stop claiming those things are unnecessary!
Subversion considered obsolete
Posted Apr 9, 2010 16:07 UTC (Fri) by vonbrand (subscriber, #4458)
[Link]
As I said, the workflow might require it. But in a decentralized environment there simply can't be any "common rallying point" for all developers handled by the DVCS, so the tool itself can't help you here.
Not by a design flaw, but by fundamental reasons: The "locking" idea only makes sense if there is one master copy shared by all.