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.
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.)
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.
> 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.
"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.
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.
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.
> 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.
"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.
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.
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 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.
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.
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.