Why is branching in SVN not good enough?

I've heard so much about how Git has redesigned how branching works, and how SVN's branching model is screwed up.

I've not used much SVN, so I have no preconceptions about what a branch should look like. I first looked at git branches, and I "get" it.

What are the practical drawbacks of SVN branches?

Answers from the POV of workflow, branching strategy an开发者_JS百科d branch performance (in terms of commit/checkout/switch times) encouraged.

Thanks, jrh

---

A few things come to mind

1. All the branches are stored in the central repository. If you're not connected to that server, or your connection to it is slow, then you can't access them quickly.
2. All the branches are stored in the central repository. This means they're public -- anyone on the team can view them. There's no way to keep a private branch that no one else has access to.
3. The DAG of commits itself contains enough information so that you can figure out which changes are included in your current version of the code, including changes from any number of branches. In svn, IIRC, this is done using an svn:mergeinfo property, which is more complicated IMHO, and is error-prone because someone might forget to commit the changed property.

---

The main problem is that Subversion makes a poor work tracking changes and merge information (for instance, directories are not first class objects and there's no true rename support). As soon as you try to port changes between branches you start getting conflicts. Some conflicts are reasonable (the same line was edited in both branches) but other have little explanation and tend to appear fairly soon when you start using branches.