Ich benutze Subversion (oft auch "svn" genannt, weil das Kommando in der Konsole so heißt) schon seit vielen Jahren. Ich hab damals in der iX davon gelesen und bin seit Version 1.0 dabei.
Trotzdem muss ich zugeben, daß ich bis gestern nicht so wirklich wußte, wie und warum man überhaupt branches macht.
Ein Branch in Subversion ist im Prinzip eine Kopie des Programms (eigentlich Quellcodes), die man an einem gewissen Punkt erzeugt, wenn man vorhat größere Änderungen daran zu machen. Denn man geht davon aus, daß im Zuge dieses Prozesses viele Dateien verändert werden müssen und es länger dauert bis man wieder eine stabile Version bekommt. Damit man trotzdem in den Genuss der Versionsverwaltung kommt, macht man eine neue Branch auf.
Wie gesagt, in Subversion ist eine Branch im Prinzip erstmal nur eine Kopie, die man anlegt. Also kopiert man einen Teil des Subversion-Baums an eine geeignete Stelle:
svn copy
svn://svn.domain.de/projekt1/hauptversion svn://svn.domain.de/projekt1/branch1
Ja, richtig gesehen, mit diesem Befehl braucht man nicht einmal eine lokale Kopie ausgecheckt haben. Man kann direkt auf dem Subversion-Repository arbeiten und dann später die Branch auschecken mit
svn checkout svn://svn.domain.de/projetk1/branch1
Das schöne an dieser Lösung ist, daß man in Ruhe an der neuen Version oder größeren Veränderung arbeiten kann, während man noch die alte stabile Version verfügbar hat und daran auch noch z.B. Bugfixes machen kann. Wenn man also während der Arbeit an der Branch einen Fehler findet, den man sofort auch in der stabilen Version ändern will, checkt man die stabile Version aus und ändert das. So hat man die stabile Version verbessert (im Zweifel sicherer und benutzbarer gemacht) ohne daß man gleich alle Änderungen an der Branch fertig haben muss.
Im Prinzip ist die Idee dahinter, daß man hinterher die Änderungen an der Branch und der stabilen Hauptversion "mergen" kann. Also so wie Subversion normalerweise die Änderungen im Quelltext bei einer neuen Revision einfügt und dabei versucht, verschiedene Änderungen an der gleichen Datei unter einen Hut zu kriegen. Das wäre natürlich der Idealfall. Man macht eine Menge Änderungen in der Branch und ein paar Bugfixes in der Hauptversion und hinterher gibt man einen Befehl ein und hat auf einen Schlag alle Änderungen aus beiden Versionen zusammen.
Das wäre wirklich ziemlich cool. Leider sieht die Wirklichkeit im Moment noch etwas anders aus. Ich habe das gestern mal versucht und musste leider feststellen, daß bei Änderungen an der gleichen Datei in der Branch und der Hauptversion (oft als "trunk" bezeichnet [kurzer Exkurs: trunk heißt Stamm, ist also die Hauptversion, während branch Ast heißt und demnach vom Stamm abgeht]) immer zu einem Konflikt führt. In meinem Fall waren das 5 Dateien. Ärgerlich dabei ist vor allem, daß die Änderungen sich auf 1 - 2 Zeilen beschränkten, die auch noch an ganz verschiedenen Stellen in der Datei standen. Normalerweise hätte Subversion die Änderungen einfach zusammengefügt und alles wäre grün gewesen. 
Soweit ich das bisher mitbekommen habe, unterstützt die neue Version 1.5 von Subversion eine etwas bessere Form des "mergens". Dabei werden dann noch Meta-Informationen zu den Dateien gespeichert, z.B. ob eine Datei schon mit einer anderen Version aus einem Branch zusammen-gemerged wurde oder nicht. Wie schon gesagt, wenn das wirklich funktioniert wäre das super und ich sofort noch mehr Fan von Subversion als bisher schon. 
Details zum Nachlesen findet man hier: Subversion Book (allerdings noch zu Version 1.4)
Die neue Version von Subversion (1.5) gibt’s auf der Herstellerseite - natürlich kostenlos. Es gibt auch noch eine Profi-Version bei CollabNet, dafür muss man sich allerdings registrieren.
PS: Eine alternative zu Subversion ist GIT, daß aus dem Ruby und Ruby on Rails Umfeld stammt und dessen Server natürlich mit Ruby on Rails läuft. GIT hat einige Features, die Subversion (noch) nicht hat und wird immer beliebter. Eine gute erste Anlaufstelle dafür ist GitHub.