5 ms·

My major problem with the people attacking svn is often that they dismiss that svn has a different set of features that may or may not suit your workflow better

My major problem with the people attacking svn is often that they dismiss that svn has a different set of features that may or may not suit your workflow better than git's. Every feature of git may be liability in some environments * I might need a controlled server with an audit-trail where any ability to rewrite history is a liability. SVN wins hands down here. * 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. * I might want the ability to mount the repo as webdav folder since I want accountants to store their XLS-Files in there without knowing what's that funky version control system. Git can't do. * I might want to commit on the road, in the plane, in my cabin in the woods. SVN fails hard. * 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. Point is: SVN is a serious VCS. It's better suited to some workflows than others, same as git. Which tool is better depends on what you're doing and what the environment you're doing this in. This is what the author of the original article forgets about. And this an ignorance that I often see in my fellow developers - and something I can't stand. The most awful piece of technology might have a spot where it really really fits. (disclaimer: I currently use git, but have been a very happy svn user for years.)

pnathan 15y ago
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. Um. git-svn and a usb key neatly sidestep that for anyone who wants to take your IP. If someone can read your IP, they can pretty much extract it. Sorry. It's also worth noting that hg is better at the immutable history idea, so if that's a criteria for adopting, hg should be looked at.
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.

pnathan 15y ago

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. Um. git-svn and a usb key neatly sidestep that for anyone who wants to take your IP. If someone can read your IP, they can pretty much extract it. Sorry. It's also worth noting that hg is better at the immutable history idea, so if that's a criteria for adopting, hg should be looked at.

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.