Have you asked your colleagues if your use of svn is causing them pain?
Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said.
But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later.
So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools?
P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.
How does git make programmer A want to disentangle the fix?
How does git keep Programmer B from making changes against the wrong base? (Admittedly, git may make it easier to move that fix from the wrong base to the right one, but it doesn't make it harder to make the mistake; if anything, a prolifiration of branches an independent lines of development makes it easier to make that mistake, not harder.)
How does git make merging easier? Doesn't it do a traditional three-way merge, just like svn? And it seems like in DVCS you have more merging, not less...
* interactive commits let you commit only parts of what you're working on. It's really easy just to commit the lines that were involved with the fix, and leave everything else alone.
* Even the best tools can be used wrong.
* It makes merging easier by making it work fast and work well. There's a lot more merging, it's not painful!
"How does git make programmer A want to disentangle the fix?"
Wrong question; the correct question is "Why does SVN make the programmer not want to disentangle the fix?" The answer is that SVN makes it a royal pain in the ass. Not impossible. Nothing is impossible. But it's a royal pain in the ass. Git makes it roughly as hard as it should be; there's a certain amount of essential complexity, but it lowers the accidental complexity to something feasible. (I use Fred Brook's "accidental" vs "essential" complexity terminology from the Mythical Man Month; if you don't know what that is, hie thee hence to amazon and acquire the Mythical Man Month.)
The reason I phrase it this way is that it's really a given that the fix should be disentangled; even SVN proponents will tend to agree with this as a matter of principle. So the question is, why have we all just gotten used to not bothering?
"How does git make merging easier?"
Again, correct question is "How does SVN make merging hard?" and the answer is "in numerous ways". However, in git, it actually works the way it always should have worked. SVN brings way too much accidental complexity to the task of merging, which is evidenced by the way people avoid it like the plague, whereas the exact same people have no problem using git for it.
"It sounds like you're handwaving!" - OK, you didn't say this but I see it coming. The answer is either Google to someone treating this subject more fully (it's not that hard to find), or try it yourself; I see no point in repeating such people's work in a limited HN comment. (Many of them have diagrams and such.) It is not comparable. It is a night-and-day difference unless you are the only person using your SVN repository, and even then git is still nicer.
> How does git make programmer A want to disentangle the fix?
From experience, I'd say it makes the process of doing so easier. In git you can:
1. commit a portion of the code, even a portion of a single file using git add --interactive
2. stash your current changes, re-make the change needed, commit, then unstash and keep working
> How does git keep Programmer B from making changes against the wrong base?
Making it easier to move the fix is exactly the point. You can't make it impossible to make mistakes, but you can make them less disastrous. Also, you can easily revert the fix in the wrong branch or remove it entirely if you haven't shared your changes.
> How does git make merging easier?
I was too scared to make branches in other systems, but my guess is that rebase is a significant part of it. If you're rebasing fairly frequently the changes you're making shouldn't diverge too much, and it makes the actual merges trivial.
You gain a lot from being able to manipulate the history of your repository. The unfortunate thing is that the history itself isn't version controlled, so you can't manipulate the history once you've shared it with other people.
One could also use SVN and GIT together. That might solve a part of the problem with not submitting fixes because of being in the middle of other set of changes. Develop using GIT locally and submit to SVN repository when ready.
What is experience of HN readers with using a combination of centralised and distributed VCS together? Have you used it and in what situations, if any, is it useful?
We use git-svn extensively at work. It is pretty good at allowing us to keep our central core dev branch going on SVN with numerous teams not using git-svn, while allowing us to do all our release branching and such in git. I would not be happy to use it in a situation where we had multiple concurrent SVN branches, but then, I wouldn't care to be using SVN there either.
You really do get the bulk of the advantages; it's not perfect, and if you have to coordinate with someone not using git it can be a challenge, but it mostly works. People were briefly annoyed at our "patch bombs" but got over it.
Have you asked your colleagues if your use of svn is causing them pain?
Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said.
But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later.
So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools?
P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.