Po pierwsze primo - branche oraz tagi w SVN tylko tak sie nazywaja, tak naprawde sa zwyklymi kopiami z jakimis tam dodatkowymi metadanymi. Mergowanie w ogolnym przypadku nie dziala, sami programisci SVN sie przyznaja ze jest to trudne (dla ciekawskich, przeczytajcie uwaznie caly rozdzial o branchach i mergach w SVN red bean book) nawet w wersji 1.7. Nie dziwie sie ze nie macie galezi.
Po drugie primo - z SVN bardzo latwo jest zmigrowac na mercuriala (hg) / gita. Polecam mercuriala bo jest duzo latwiejszy na poczatek, lecz jesli sie nie boicie to sprobujcie oba (git ma duzo trudniejsza linie polecen, ale sam w sobie jest prosty).
Po takiej migracji wszelkie problemy z branchami i mergami odchodza w niepamiec.
Pozwoli to na bardzo proste zarzadzanie aplikacja.
Wersja gdy jest wielu klientow i maja rozne stany (skoro nie wersjonujecie ;d) aplikacji - np. biezace programowanie na masterze (git) / default (hg); nowe releasy zaczynaja nowe branche na ktorych robione sa bugfixy; nowe funkcjonalnosci to rowniez nowe branche. Zaimplementowanie nowego featuresa powoduje merge z master / default; bugfixy dodaje zmany na release branchach nie ditykajac nowych niegotowych featursow. Instalacja releasa z bugfixem nie wymusza rowniez instalacji nowych featuresow, o ktorych release branch po prostu nie ma pojecia. Bugfixy z releasow musza najczesciej sie dostac rowniez do default / mastera, co jest banalnym mergem / graftem (hg) / cherrypickiem (git) z releasa na default / master. Jesli bugfix jest potrzebny w kazdym releasie, szukacie najmlodszego wspieranego brancha z bugiem, robicie fix, mergujecie / graftujecie / cherrypickujecie (:D) to do nastepnego pod wzgledem wieku releasa, i tak dalej (to nie jest niezbedne, ale doswiadczenie mowi mi ze pozwala na latwe merge, gdyz z wersji na wersje zmiany sa dosc male i latwo sie polapac co zmienic), ostatecznie z najnowszego releasa idzie merge na default / master aby i tam byl fix. Bugfix backporty sa rownie proste.
W ten sposob macie w sumie niejawne proste wersjonowanie aplikacji, ale nie musicie tego uzywac. W sensie - po bugfixie mozecie zainstalowac wersje z tego samego release brancha z bugfixem (uzywacie wersji aplikacji) lub po prostu budujecie default / master po tym jak bugfix tam sie rowniez znalazl i instalujecie to. Nie uwazam tego drugiego za dobry pomysl.
Gdy macie tylko jednego klienta i chcecie zawsze mu dawac najnowsza wersje, po prostu olewacie release branche i robicie male bugfixy od razu na default / master, lub dla duzych osobne branche i jak gotowe robicie merge, po czym build i instalacja tego ostatniego kodu.Branche z nowymi featurami sa niezalezne i nie przeszkadzaja / nie rozgrzebuja kodu.
Jelsi jest duzo nowych featerow i sa dynamicznie rozwijane, i jest duzo bugfixow i sa czeste (zespol 10 programistow to juz cos), polecam w feature branchach robic raz na jakis czas (zalezy od dynamiki projektu - raz na dzien wieczorem, raz na 3 dni, raz na tydzien) robic merge z defaulta / mastera do feature brancha - zapobiegnie to pozniej trudnych mergy powrotnych, majacych na celu integracje feature z defaultem. Ale to tez zalezy czy inne featuresy maja byc wciagniete czy nie...
Dobra jest zasada - master / default, lub jakis dedykowany branch, np. stable, sa stabilne i zawsze dzialaja. Jak cos nie dziala (Jenkins sie wywalil) to caly zespol naprawia. Osobiscie nie uzywam za czesto dedykowanego stabilnego brancha, default (wole hg) najczesciej w zupelnosci wystarcza.