5 ms·

I worked once on a project which used a Pick database. If you don't know what that is, thank the fates. While I worked on it, I dutifully read the mailing lists

I worked once on a project which used a Pick database. If you don't know what that is, thank the fates. While I worked on it, I dutifully read the mailing lists and such to learn what I could about this technology. This experience taught me that every awful piece of technology has a halo of zealots who think it's the greatest, and is just now (still) on the verge of taking over its field. And should you hint that there might be anything better, they have a litany of reasons why you are the problem, because you don't understand it. The whole thing is about as odd as watching the domestic life of someone who has married their vacuum cleaner. Some of the defenders of subversion here reminded me of that experience. The more truculent defenders slash at those who point out its deficiencies with remarks about their ignorance of subversion, and if you don't take a couple of weeks out of your schedule to learn its thorny ways then you deserve your problems. The milder defenders will equivocate and claim that its just a preference, and that subversion isn't nearly as painful as long as everyone on the team always unfailingly follows this list of 178 rules on what not to do.

Xylakant 15y ago
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.

Xylakant 15y ago

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.