CVCSes work OK. But they all miss a critical piece. They aren't nearly as good at doing one of the main things that a version control system can let you do: branching and experimenting with your code
I hear this complaint a lot, but I do this all the time with SVN. Just have a directory (tempbranches) where you create your branches. It's probably something I do once a week (and not because I feel limited to only doing it once per week, but most of my work occurs in my local branch -- and I branch that one only when I want to do something that is more experimental, but will take a few days). I'll grant that its not as clean as a DVCS for this, but it works just as easily. The big difference is that we now have centralized accounting of this action, rather than it being distributed.
Um, are you sure? I find branching and merging in git (after three months using it) much, much, much easier than I did in SVN (after 7 years of using it).
Can you expand. Because I've probably done a few hundred SVN branches. And probably 100 Git branches. The big advantage I had with Git was that since it is decentralized, you don't have branches on the server (so no need to have a tempbranch target on the server). But that doesn't seem like a huge deal to me.
The actual activity of branching and merging seem equally easy to me.
With just 100 hundred git branches, I think you're not really using git often and/or to its potential. On a busy coding day, I easily create a few branches. If you also count temporary branches on non-development testing machines (I do driver development on Linux for fun) that can easily reach a dozen.
Now what for? I create branches to test merges with other developers code, branches before refactoring my in-progress stuff (so I can go back and pick up the original branch with all its history in case it was a dead-end). I do new branches for simple fixes, tracking down bugs (versioning all test-patches so you can check the next day/week what theories you've already tested is sometimes extremely useful). Sometimes I just do a new branch to get the feel of starting with a clean slate.
Once a month or so a look at all the branches lying around and delete those no longer useful.
All this is only possible because git branching is _cheap_. Orders of magnitudes cheaper than on any central rcs. And the best part is that git never ever loses anything. git reflog shows you _all_ the states you've gone through to the current one. So all these branches are actually valuable.
Relatively unscientific, but git merges feel smarter. It notices when I've moved a file (without telling it I did), and I experience fewer conflicts that I was used to. Some possible suggestions as to why here:
Also, the fact that commits have an atomic life is useful. If I cherry pick a change into a branch and then later merge it, Git generally knows what's up. With SVN this sort of scenario seemed to confuse things. Another advantage to this model is that it's very easy to compare (what commits differ between these, instead of a big code diff).
The differences may be subtle, but all in all I find myself much happier and more likely to use branches than I used to.
I can cherry pick easily when I merge back. I just select which revision range I want to merge in. I can say revision 1, 2-5, and 11.
I think I do lose history though. And while history is important, if its just history, why don't people say that? People make it sound like you just can't do branches and merging in SVN easily, while you can.
Try to have a team of developers working on various parts, you modify a function to add some code to it, another developer moves the function to the bottom of the file, and yet another developer modifies the code to fix an off by one error.
Git will happily merge the result together, in all of the cases I've seen it will do so without even needing user intervention and everything ends up where it should be. With subversion this is a nightmare. If code changes location in a file suddenly merge'ing in more changes becomes problematic.
Recently my boss and I were working on different parts of the same project. I proceeded to move a whole bunch of stuff around to clean up the entire source tree, in the mean time he had added two more files and made modifications to some of the ones I had moved. I then proceeded to merge in his changes, git happily merged in his changes to the now moved files, and added the new files into the original location I had just moved, I moved them, committed and everything was happy. We tried the same thing in Subversion not too long ago and it was a complete mess leaving huge merge issues that took a developer a while to figure out what was going on.
Try to have a team of developers working on various parts, you modify a function to add some code to it, another developer moves the function to the bottom of the file, and yet another developer modifies the code to fix an off by one error.
We have a team working on various parts of code every day. Like literally every day. Merge conflicts do occur, but they're not the common case. It occurs infrequently enough that its not a big deal. And probably a quarter of the time the conflict is something you didn't want merged.
I proceeded to move a whole bunch of stuff around to clean up the entire source tree, in the mean time he had added two more files and made modifications to some of the ones I had moved. I then proceeded to merge in his changes, git happily merged in his changes to the now moved files, and added the new files into the original location I had just moved, I moved them, committed and everything was happy. We tried the same thing in Subversion not too long ago and it was a complete mess leaving huge merge issues that took a developer a while to figure out what was going on.
That I do see happen. SVN doesn't like changes to directory structure... merges or not.
The problems occur when you make substantial changes in a branch and then you go to merge it back. SVN has several issues how it merges things. Probably the biggest issue is that SVN can't properly merge file renames. Second it does 2-way merges as opposed to Git's recursive 3-way merges (I assume Hg does something similar). Recursive 3-way merges are much much better at resolving conflicts. Finally, SVN has some issues with merging a branch multiple times. This is because SVN doesn't have a natural way to record merges in history. I've heard that this last issue has improved in newer versions but it doesn't sound like it has completely gone away.
I hear this complaint a lot, but I do this all the time with SVN. Just have a directory (tempbranches) where you create your branches. It's probably something I do once a week (and not because I feel limited to only doing it once per week, but most of my work occurs in my local branch -- and I branch that one only when I want to do something that is more experimental, but will take a few days). I'll grant that its not as clean as a DVCS for this, but it works just as easily. The big difference is that we now have centralized accounting of this action, rather than it being distributed.