Verständnisproblem: SVN für Projekt mit Kundenanpassungen

[HoPi]

Moin

Ich hab da wohl ein paar Verständnisprobleme, was das Tagging und Branching in SVN angeht.

Bis vor ein paar Jahren war ich ein einzelner Entwickler für ein Web-Projekt, wollte aber trotzdem irgendeine Versionskontrolle benutzen. Also hab ich mein Projekt, wie es damals vorlag, in trunk geschoben, in ein neues Verzeichnis ausgecheckt und dort meine Arbeiten gemacht. Wenn ich fertig war, gab es ein Commit inkl. Kommentar und ich habe eine Kopie der trunk-Version ins Produktiv-System gemacht, damit meine Anwender damit arbeiten konnten. Hat gut geklappt, alles schön und gut. Mit Tags und Branches hab ich mich nie beschäftigt.

Nun sitzen wir mit mehreren Leuten an einem Projekt, bei dem es auch um Kunden-spezifische Anpassungen geht. Ich hab nun den halben Arbeitstag damit verbracht, zu recherchieren, was es damit nun auf sich hat... und bin ratloser als zuvor.

Ich mach mal ein Beispiel

Ich hab eine Pseudo-Klasse mit folgenden Bestandteilen:

function doSomething() {
   return something;
}

function doNothing() {
   return nothing;
}

Nun gleich die erste Frage: wo checke ich die Datei in einem leeren Repository ein? Einfach in trunk? Oder wird ein Branch erzeugt?

Nun kommt eine neue Funktion hinzu:

function doSomething() {
   return something;
}

function doNothing() {
   return nothing;
}

function doLotsOfStuff() {
   return lotsOfStuf; // <-- dafür muss es später einen Bugfix geben
}

und das Projekt kann ausgeliefert werden (weil der Bug ja nicht wirklich im Quellcode kommentiert wird ). Nächste Frage: Was mache ich jetzt? Einen Tag? Einen Branch? Kommt die Änderung in trunk?

Dazu kommen jetzt noch Kunden-spezifische Anpassungen, die ich natürlich auch irgendwie ins Repo kriegen muss. Bevor ich die Fragen, die ich dort habe, aber stelle, bin ich erstmal darauf angewiesen, das zu verstehen, was ich bisher geschrieben
Ich hoffe, jemand kann da Licht ins Dunkle bringen...

 

[Der Wolf]

Hallo,

also normalerweise ist es glaube ich so, dass der "trunk" den Main-Zweig eines Produktes darstellt und <b>immer</b> stabil sein sollte. Alle Entwicklungen, die gerade durchgeführt werden, finden wohl in einem branch des trunks statt und wenn sie abgeschlossen sind, werden die Änderungen zurück in den main/trunk Zweig gemerged.

Den Tag Ordner kann man dann verwenden um spezifische Versionen zu taggen, die zum Beispiel an Kunden rausgegangen sind. Dazu einfach eine Kopie vom "trunk" oder "branch" in den Tags Ordner machen. Kommt vom Kunden jetzt eine Anfrage bzw ein Bug-Report kannst du die Kunden-Version aus dem Tags Ordner auschecken und hast wieder genau die Version des Kunden ohne das Kompilat separat speichern zu müssen.

Gruß,
Wolf

 

[ikosaeder]

Man kann es auch anders machen, das der Trunk immer die aktuellste Alpha Version darstellt und für einen Release ein Branch erstellt wird. Bei diesem Branch werden dann keine Features mehr hinzugefügt (Freeze) und nur noch Tests und Bugfixes gemacht. Je nach Status kann man diesen Branch dann Taggen, z.B. mit Beta, Release Kandidate, Stable etc. Dazu hat jeder Entwickler einen eigenen Branch, in dem er die tatsächliche Entwicklung macht, und der unter Umständen auch nicht funktionierende Versionen enthalten kann. Fertige Änderungen werden in den Trunk gemerged und dann getestet. Konkret zu der Pseudoklasse: Diese wird in einem Entwicklerbranch erzeugt und entwickelt. Erst wenn die Funktionalität voll implementiert ist, wird diese Klasse /Funktion / DAtei in den Trunk eingepflegt. Zur Klarstellung, ein Branch ist eine Kopie des Quellcodes, der sich in eine komplett andere Richtung entwickeln kann, ein Tag ist nur ein Bezeichner, der einen bestimmten Stand des Codes anzeigt. Für Kundenspezifische Änderungen ist daher immer ein Branch sinnvoll und ausgelieferte Versionen dieses Branches werden entsprechend getaggt. Wichtig ist, das auch diese Kunden Branches regelmäßig mit den Änderungen im trunk gemerged werden.