No, I'm pretty sure I'm with you. One person 'checks out' a file to edit and the rest of the people see it as locked. But I remember conflicts when working wit

No, I'm pretty sure I'm with you. One person 'checks out' a file to edit and the rest of the people see it as locked. But I remember conflicts when working with that style of locking. The biggest was people forgetting to check their work in before leaving and kept anyone else from using it, but also people not checking the permissions before editing, and people who didn't have the lock editing it anyways knowingly because they had to fix a bug and didn't have time to do it right. If we were using a dvcs (and no locking mechanism) we'd have been using our communication tool (then just email and calendaring) more and posting things like "I'm going to fix bug #... - this is going to require a rearchitecting foo.c and touching all of foo_*.c and all accompanying headers". This way it's not preventing someone from working on things, it's warning them of potential conflicts that would have to be merged. As long as these conflicts seem small people are welcome to keep developing next to me. There's no reason to use a giant lock on a whole file. But also, this schedules my intent in a semantic way - people can see it and say "Whoa, you'll need to break bar.c as well and Dave's doing delicate work there." whereas if I'd just locked files nobody would have known to warn me and I'd have gotten half-way to a working change to be stalled by Dave's project. Worse, Dave would probably have needed my files to finish his work leading to a nasty conflict.