FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard.
Having said that, branching seems pretty simple in svn if you really like having them.
Having said that, branching seems pretty simple in svn if you really like having them.
Also, my experience, as non-representative as it is, has shown that cheap branching with efficient merging results in much less of a mess than everybody playing in the same sandbox and inevitably kicking everybody else's sand castles.
That just points to poor collaboration management etc though. If people don't work together properly, you're just delaying problems until people merge anyway.
The fact that DVCS allows for less rigid management alo explains why DVCS became popular so quickly in open source, I think (where the kind of collaboration managements you suggest does not scale very well).
Or you do your development in a way that doesn't break the build, and do it in several steps.
For example, just build new code that can be specified to be used at runtime, then when it works just like the existing default code, switch it over (Effectively doing your own branch).
Just as you believe that a proper social structure and sufficiently clear conventions can overcome deficiencies in software, I believe the oposite - the capabilities and limitations of software can enforce certain patterns of behavior. And in my experience DVCSs end up having more of a positive effect on the development process.
Git made popular the use of branches for almost everything, but branches have been used way before DVCS became popular. It just happened to be that besides cvs/svn, all the non peculiar open source systems are DVCS, but working merge caps and branch managements are not specific to DVCS (but DVCS would be unusable without it).
With Git, branching is simple and really fast. It can also be done in such a way as to prevent your own personal development and feature branches from making it back into the central repo.
I've also found that cherry picking commits between branches and squishing small commits help me maintain the cleanliness of our repos (At no point in the history of our central repo is there half of a new feature or fix).
In Git, branches are an inherent part of the repository graph structure. So the relationships of branches and merges are very low level and stable and work quite reliably in all situations.
Because of this I trust Git more for branching/merging.
Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess.
I much prefer doing branches in the source code (If that makes sense).
For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.
Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end.
Except you can trivially have multiple of these things going at a time.
I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
Let me restate: I do not like branches and use them very rarely.
So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?
The ability to version control your project (even without branching you can checkin) when disconnected (from your network).
Maybe that's a good selling point for people who aren't connected to the net much though,
Yeah Right :-P Obviously I meant if you were working on a project with its repository on a remote server. Assuming you want local version control (as you seemt o do, since you are locally installing svn) you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online?
And if you had two laptops say (apart from the remote server) , you'd maintain 3 repositories?
Technically speaking, svn merge is more akin to cherry-pick in git/hg/etc..., where the "merged" commits are not recorded as such, but as totally new commits.
Note also that bad svn merging capabilities are specific to svn, not to centralized VCS (perforce, etc...). It is not so much that DVCS are better than svn as much as svn worse than everything else.