4 ms·

> Every feature of git may be liability in some environments Scoff. > I might need a controlled server with an audit-trail where any ability to rewrite histor

by wnight 15y ago

> Every feature of git may be liability in some environments Scoff. > I might need a controlled server with an audit-trail where any ability to rewrite history is a liability. SVN wins hands down here. No, it does not. Nobody can mess with YOUR git repo and while they can make their repo look like whatever they want, they could do that with any program by replaying/recording a chosen history. Moreover, git uses the content hash as an identifier so even if history is rewritten, you automatically know. > I might want the ability to lock binary files since my repo is mainly a set of designs created by the gfx people. SVN wins. Only binary files? But fine, there are numerous ways you could prevent this from happening with hooks, 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. > On the contrary, maybe my environment is such that the svn server is on the local network and I actually feel uncomfortable with people running around with their laptops and all of my VCS history on them. Git fails hard. This strikes me as a made-up fear. Are you this paranoid about browser cache files from developers browsing the repo? Editor caches? If you've got secrets presumably they'd be easily leaked from specific single files. It's not like the attacker would need to achieve a 100% repo duplicate to win - having any company files accessible is a lose, even if they didn't happen to be sensitive this time. But anyways, let's say you've locked everything else down except git. Two choices, (well, and uncountable others no doubt, but...) break the project into submodules you would be willing to lose, or use git fully - on a VPN-only share, such that then the laptop gets turned off the repo goes away. > SVN is a serious VCS. Not in the way you mean it, a serious contender. Using it cripples a project by requiring it to work the SVN way, a slow painful, second-only-to-VSS way. It's not like it needs to be ripped out as a security hole (that I know of), but nobody should consider using it for new projects, or should have in the past few years.

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.

by wnight 15y ago

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.