4 ms·

"but even if someone did slip past and checked in a change to a file you had forgotten to protect you can see that change and revert it trivially. Catastrophe a

by to3m 15y ago

"but even if someone did slip past and checked in a change to a file you had forgotten to protect you can see that change and revert it trivially. Catastrophe avoided." - this must be a terminology issue? "locking" refers to a per-file mutex that must be acquired before the working copy can be edited or committed. It's usually enforced to some extent using the writability attribute on the working copy files. (Obviously, you can subvert this to some extent using `chmod +w' or whatever - it's not magic.) Acquiring the lock may also force the latest version on you in some systems. This is (these days, anyway) to help people correctly serialise their changes to unmergeable files.

wnight 15y ago
That's handled by not merging changes into the master branch of the master repo unless you mean to. Anyone gets to see the files as changed, you get to choose who to listen to. And, if you forget to pay attention and listen to the wrong set of changes, you can trivially revert any piece of it. > this must be a terminology issue? "locking" refers to [...] I hadn't understood exactly what locking entailed, but I don't think it changes the issue much.
- to3m 15y ago
  The problem comes if two people have changed the same file in different ways, and you want both changes. What are you going to do? There's no 'wrong' set of changes that you can discard. If you lose one and keep the other, that means somebody's work gets lost, and they have to redo it - so you need to merge. Will you sit there in Photoshop, carefully pasting together the modified bits? Will you open 2 copies of 3D Studio or Maya or what have you, and painstakingly join the two models together?? Well... I'd hope not. Fortunately, as with many problems, there is a perfect solution, which is to (try to) not have that problem in the first place. It just needs a bit of process. Locking is a nice and easy way of introducing a process that works, and that anybody can understand, all without their needing to know the first thing about how the mysterious computer-ma-bob actually works. You can do without it, but it just makes life difficult if the team is distributed, tiresome if they are not, and error-prone in either case. I don't have any real idea how you'd go about adding such a thing to git. Perhaps it wouldn't even be possible. That doesn't make it any less useful, though. If you don't like the idea of SVN doing something useful that git doesn't even try to support, consider the two as solving somewhat different problems.
  - wnight 15y ago
    > The problem comes if two people have changed the same file in different ways, and you want both changes. What are you going to do? There's no 'wrong' set of changes that you can discard. Well, as you say ... > there is a perfect solution, which is to (try to) not have that problem in the first place Why are two people both returning the same work? That's a process control issue you're having and a filesystem hack isn't going to solve that. > Locking is a nice and easy way of introducing a process that works, and that anybody can understand, all without their needing to know the first thing about how the mysterious computer-ma-bob actually works. Not in the slightest. With locking you'd have a confused person trying to save two hours of their changes, wondering why it isn't working. Eventually they'll save to a temp file and still have all the same merging work to do, but they can't do it with the versioning tool so you're pretending it's not there. > Will you sit there in Photoshop, carefully pasting together the modified bits? Yeah yeah, binary files. No simple merge. But you wouldn't want the change from the person who shouldn't have made it, so you wouldn't take it and there wouldn't be a problem. If you do want their work they'll have to redo it in turn, based on the latest set of changes. > I don't have any real idea how you'd go about adding such a thing to git. Simple, you'd have a list of files that shouldn't be edited, or with the name of who should be editing them. A script would run at checkout and set appropriate permissions for each. I'm sure there are a few other ways too. But why? Are your teams really just working on whatever files aren't locked? Do you really need this tool to do this? > Perhaps it wouldn't even be possible. That doesn't make it any less useful, though. Perhaps git already does it. That doesn't make it useful. Do your team communication and synchronization with a communication tool and leave the filesystem permissions alone. There is no central repo that needs protection, contention isn't a failure. > If you don't like the idea of SVN doing something useful that git doesn't even try to support, consider the two as solving somewhat different problems. I'm sure there are many valid capabilities of most programs that I don't know of, or don't fully appreciate the uses for. This seems like a misfeature though.
    - to3m 15y ago
      "If you do want their work they'll have to redo it in turn, based on the latest set of changes." - and this is exactly the problem that locking is trying to help solve. I don't see how you can state that contention isn't a failure, if people are then to have to redo work! These are real people, presumably working to some kind of deadline. They have better things to do (and their paymasters have better things to spend their money on) than spend time redoing changes that they've already done. (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! Sadly that is not the case...) As for using an external tool or process to manage the locking, perhaps one has to actually experience this approach in person to appreciate its limitations? Or maybe what's in my mind's eye is different from what's in yours? Anyway, I would not recommend doing this myself.

by to3m 15y ago

wnight 15y ago

That's handled by not merging changes into the master branch of the master repo unless you mean to. Anyone gets to see the files as changed, you get to choose who to listen to. And, if you forget to pay attention and listen to the wrong set of changes, you can trivially revert any piece of it. > this must be a terminology issue? "locking" refers to [...] I hadn't understood exactly what locking entailed, but I don't think it changes the issue much.

to3m 15y ago
The problem comes if two people have changed the same file in different ways, and you want both changes. What are you going to do? There's no 'wrong' set of changes that you can discard. If you lose one and keep the other, that means somebody's work gets lost, and they have to redo it - so you need to merge. Will you sit there in Photoshop, carefully pasting together the modified bits? Will you open 2 copies of 3D Studio or Maya or what have you, and painstakingly join the two models together?? Well... I'd hope not. Fortunately, as with many problems, there is a perfect solution, which is to (try to) not have that problem in the first place. It just needs a bit of process. Locking is a nice and easy way of introducing a process that works, and that anybody can understand, all without their needing to know the first thing about how the mysterious computer-ma-bob actually works. You can do without it, but it just makes life difficult if the team is distributed, tiresome if they are not, and error-prone in either case. I don't have any real idea how you'd go about adding such a thing to git. Perhaps it wouldn't even be possible. That doesn't make it any less useful, though. If you don't like the idea of SVN doing something useful that git doesn't even try to support, consider the two as solving somewhat different problems.
- wnight 15y ago
  > The problem comes if two people have changed the same file in different ways, and you want both changes. What are you going to do? There's no 'wrong' set of changes that you can discard. Well, as you say ... > there is a perfect solution, which is to (try to) not have that problem in the first place Why are two people both returning the same work? That's a process control issue you're having and a filesystem hack isn't going to solve that. > Locking is a nice and easy way of introducing a process that works, and that anybody can understand, all without their needing to know the first thing about how the mysterious computer-ma-bob actually works. Not in the slightest. With locking you'd have a confused person trying to save two hours of their changes, wondering why it isn't working. Eventually they'll save to a temp file and still have all the same merging work to do, but they can't do it with the versioning tool so you're pretending it's not there. > Will you sit there in Photoshop, carefully pasting together the modified bits? Yeah yeah, binary files. No simple merge. But you wouldn't want the change from the person who shouldn't have made it, so you wouldn't take it and there wouldn't be a problem. If you do want their work they'll have to redo it in turn, based on the latest set of changes. > I don't have any real idea how you'd go about adding such a thing to git. Simple, you'd have a list of files that shouldn't be edited, or with the name of who should be editing them. A script would run at checkout and set appropriate permissions for each. I'm sure there are a few other ways too. But why? Are your teams really just working on whatever files aren't locked? Do you really need this tool to do this? > Perhaps it wouldn't even be possible. That doesn't make it any less useful, though. Perhaps git already does it. That doesn't make it useful. Do your team communication and synchronization with a communication tool and leave the filesystem permissions alone. There is no central repo that needs protection, contention isn't a failure. > If you don't like the idea of SVN doing something useful that git doesn't even try to support, consider the two as solving somewhat different problems. I'm sure there are many valid capabilities of most programs that I don't know of, or don't fully appreciate the uses for. This seems like a misfeature though.
  - to3m 15y ago
    "If you do want their work they'll have to redo it in turn, based on the latest set of changes." - and this is exactly the problem that locking is trying to help solve. I don't see how you can state that contention isn't a failure, if people are then to have to redo work! These are real people, presumably working to some kind of deadline. They have better things to do (and their paymasters have better things to spend their money on) than spend time redoing changes that they've already done. (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! Sadly that is not the case...) As for using an external tool or process to manage the locking, perhaps one has to actually experience this approach in person to appreciate its limitations? Or maybe what's in my mind's eye is different from what's in yours? Anyway, I would not recommend doing this myself.