4 ms·

Did you miss my discussion of the problems of permission-based locking? You dismiss "using external tools" when this is a communication issue, not a permission

by wnight 15y ago

Did you miss my discussion of the problems of permission-based locking? You dismiss "using external tools" when this is a communication issue, not a permission issue. What better achieves the desired results? 1) Having many files, only some of which you can save changes to, but working on those files otherwise totally unguided when you can. 2) Having many files, all of which you can edit, but only some of which you have been told via email or IM to work on. Obviously (I think) #1 is a joke and #2 is the only practical way to go. > As for using an external tool or process to manage the locking You're thinking of it from the wrong point of view. From the POV of the development manager using gantt charts, using the CVS permissions to convey intent is that horrid external tool. > I don't see how you can state that contention isn't a failure, if people are then to have to redo work! I didn't say that. I said it's not a failure of the VCS. It's a failure of the process that led the people to doing two inherently unmergeable things. As I said in that post, they'd still have done the useless work but they'd simply have saved it under a temp filename after finding out the file was write protected. Then - as you read, I said they'd have to do the painful merge anyways - or watch their work be totally wasted. > These are real people [...] better things to do [...] paymasters have better things [...] than spend time redoing changes that they've already done. Yeah yeah, I get it. But you're missing the point. I'm saying developers waste more time doing this your way, despite the locking. btw, redoing changes they've already done is redundant. > It sort of sounds like you don't think non-programmers would ever have the need to edit a file at the same time as anybody else might be editing it! Not at all. But the non-programmers are less likely to notice the permissions and deduce their ultimate reason and impact and do the right workflow thing. Falling back on the false security of a broken process instead of fixing it is like using broken crypto - you think you're doing well but you'd be better off if someone painfully opened your eyes and realized you were totally insecure all along.

to3m 15y ago
This is all so contrary to my experience, that I can only assume we are actually talking about completely different things. At best, I must simply be explaining myself poorly. (See, e.g., http://en.wikipedia.org/wiki/Revision_control#File_locking http://en.wikipedia.org/wiki/Revision_control#File_locking for a brief description. I tried to keep my description brief, but perhaps it came too close to 'cryptic'... apologies...) Anyway, should you ever meet one of these systems in practice, rest assured that the problems you suggest will happen, won't.
- wnight 15y ago
  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.
- deleted 15y ago
  [deleted]

by wnight 15y ago

to3m 15y ago

This is all so contrary to my experience, that I can only assume we are actually talking about completely different things. At best, I must simply be explaining myself poorly. (See, e.g., http://en.wikipedia.org/wiki/Revision_control#File_locking http://en.wikipedia.org/wiki/Revision_control#File_locking for a brief description. I tried to keep my description brief, but perhaps it came too close to 'cryptic'... apologies...) Anyway, should you ever meet one of these systems in practice, rest assured that the problems you suggest will happen, won't.

wnight 15y ago
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.
deleted 15y ago
[deleted]