8

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 and branch performance (in terms of commit/checkout/switch times) encouraged.

Thanks, jrh

jrharshath
  • 25,975
  • 33
  • 97
  • 127
  • 3
    I don't use Git or any other DVCS, but this http://hginit.com/00.html and this http://kiln.stackexchange.com/questions/892/how-will-mercurial-be-better-than-subversion-when-one-user-refactors-code-and-ano might be helpful to you. – sharptooth Dec 01 '10 at 07:15
  • At least - SVN hasn't originally designed "branches" as separated entity. And even now - there are no branches, there are just copy of dirs/files and handling what revisions were merged. Just try to work with mercurial or git and amaze how simple can the work with branches be. – zerkms Dec 01 '10 at 07:29
  • I don't know much about the internals but I think that branching in SVN is a matter of 'copying' all the files to other location and in Git it's all about tagging the code – jab Dec 01 '10 at 07:31
  • It also has to do with merging: http://stackoverflow.com/search?q=[svn]+[git]+merge, as in http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn – VonC Dec 01 '10 at 07:32
  • The article at http://hginit.com/00.html contains some wrong statements (Subversion *does* handle the concept of changeset; it just makes it badly) but it gives an excellent explanation about why distributed VCS both allows centralized storage and actually improves it. Nice reading. – Álvaro González Dec 01 '10 at 11:30

2 Answers2

5

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.
Tyler
  • 21,762
  • 11
  • 61
  • 90
1

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.

Álvaro González
  • 142,137
  • 41
  • 261
  • 360