[Ben]

Hallo,
ich habe eine Frage zum richtigen Branchen mit z.B. Subversion.

Ich arbeite mit dem Zend Framework (ZF), derzeit in Version 0.6, Ende der kommenden Woche in Version 0.7 verfügbar.
Nun würde ich gerne die Version 1.0 meiner Anwendung basierend auf der Version 0.7 des ZF umsetzen, damit ich nicht ständig mit dem Updaten und eventuellen Portieren der Anwendung beschäftigt bin. Bis zu Version 1.0 des ZF kann sich ja noch einiges tun, auch was grundlegende strukturelle Dinge angeht.

Steht Version 1.0 meiner Anwendung würde, würde ich dann auf die aktuelle Version des ZF umsteigen (ist ja egal, welche das dann sein wird).

Die erste Frage ist nun:
Ist so ein Vorgehen zu empfehlen?

Ich denke eben, dass es nicht machbar ist ständig auf Portierungen acht zu geben, da man ja ansonsten Gefahr läuft mehr anzupassen, als weiter zu entwickeln!


Die zweite Frage betrifft dann die Handhabung des branchs in Subversion.

Ich habe derzeit zwei Gedanken, was nicht heißt, dass es nicht mehr geben kann bzw. gibt.

Ich entwickle die Version 1.0 der Anwendung im trunk und lege dann nach der Fertigstellung einen branch mit diesem Programmstand an und entwickle dann im trunk weiter mit der aktuellen Version des Frameworks.

Ich lege einen branch an, wenn die Version des ZF veröffentlicht wird, mit der ich arbeiten will und teste im trunk parallel aus, ob auch aktuelle Versionen des Frameworks mit meiner Anwendung kompatibel sind.


Irgendwie würde ich jetzt eher einen Mix aus beiden bevorzugen, weiß aber eben nicht, wie ich das bewerkstelligen kann.

Ich danke im Voraus für Eure Hilfe.
Grüße, Ben.

[Basti]

Hi.

Das Branchen macht ja eigentlich nur Sinn, wenn du auch beide Versionen zumindest ein Stück weit parallel weiterentwickeln magst. Aber klar, wenn du nicht sicher bist, dass du das Refactoring (bzw. Portierung auf andere Framework-Version) hinbekommst, dann leg dafür einen Branch an, probiers und wenns klappt bringst du das Ergebnis in den Trunk ein.

Basti

[Ben]

Zitat von Basti

Das Branchen macht ja eigentlich nur Sinn, wenn du auch beide Versionen zumindest ein Stück weit parallel weiterentwickeln magst.

Jau, darum geht es aber ja irgendwie nicht. Das ist ja mein Problem.

Ich kenne das so, dass man einen branch für einen Programmstand anlegt und dann separat weiterentwickelt, z.B. weil ein Kunde den Programmstand 3.6 hat und dort nun individuelle Anpassungen gemacht werden.
Gleichzeitig wird aber im trunk die allgemeine Weiterentwicklung, die sich nicht unbedingt mit der Entwicklung im oben genannten branch vertragen muss, weitergeführt.

Diesen Fall habe ich jetzt aber eher nicht.
Ich habe ja die Situation, dass ich jetzt schon weiß, dass sich das Framework, welches ich nutzen möchte/werde in den kommenden Monaten relativ schnell weiterentwickeln wird und man somit nicht vor signifikanten Strukturänderungen sicher ist, um das mal so grob zu sagen.

Wenn ich mir jetzt v0.7 auswähle, dann weiß ich natürlich auch, dass z.B. in v0.8 ein paar Sachen dabei sein werden (wahrscheinlicherweise jedenfalls), die ich ganz gerne auch schon in v0.7 hätte.
Wie gehe ich nun mit diesem Wissen um? Wie organisiere ich die Entwicklung?

Ich würde es wahrscheinlich so machen, dass ich einen separaten Zweig erstelle, welcher auf v0.7 basiert und somit der Konfiguration den Voraussetzungen des live-System entspricht. In diesem Zweig wird dann v1.0 der Anwendung entwickelt.

Gleichzeitig wird aber im trunk ständig versucht die Anwendung auch auf Basis anderer Versionen des Frameworks laufen zu lassen, beispielsweise v0.8 oder v0.9. So erhält man schon zur Entwicklungszeit von v1.0 der Anwendung Informationen darüber, was für Probleme eventuell bei der Portierung zu und Entwicklung der Version 2.0 der Anwendung auftreten können.
Läuft die Anwendung fehlerfrei auf höheren Framework-Versionen, so ist es nur folgerichtig, dass man die Möglichkeiten der neuen Versionen nutzt und die Anwendung im live-System updatet. Da braucht man dann aber nicht mal einen Versionssprung durchzuführen (was die Anwendung angeht).


Durch die Tests, die parallel zur Entwicklung durchgeführt werden entsteht aber ein Problem. Man müsste ja ständig nicht nur in den branch commiten, sondern auch der trunk müsste immer auf dem aktuellen Stand sein, um eben Testen zu können, ob die Anwendung läuft.
Da tritt dann das nächste Problem auf. Was macht man, wenn die Anwendung nicht läuft. Fixed man das oder nicht?
Wenn nicht, dann wird logischerweise nach dem nächsten commit, sofern an dieser Stelle nichts geändert wurde, auch wieder ein Misserfolg vorzufinden sein.
usw. usf.


Ich hoffe Ihr versteht mein Problem?
Bin mir nicht sicher, ob ich das gut genug beschrieben habe.

[Basti]

Zitat von Ben

Gleichzeitig wird aber im trunk ständig versucht die Anwendung auch auf Basis anderer Versionen des Frameworks laufen zu lassen, beispielsweise v0.8 oder v0.9. So erhält man schon zur Entwicklungszeit von v1.0 der Anwendung Informationen darüber, was für Probleme eventuell bei der Portierung zu und Entwicklung der Version 2.0 der Anwendung auftreten können.

So gesehen ist aber die Entwicklung bis hin 1.0 (unabhängig von der Framework-Version) der Haupt-Entwicklungs-Strang und die Portierungen sind Abzweigungen davon, die wieder zurückgeführt werden, wenn sie gelungen sind, oder?

So fände ich das in jedem Fall übersichlicher. Allerdings bleibt die Frage, wozu überhaupt einen Branch, wenn nicht an beiden Zweigen gearbeitet wird. Wenn es nicht unbedingt nötig ist, würde ich es schwer vermeiden, zwei Zweige gleichzeitig zu pflegen und ggf. später wieder zusammenführen zu müssen. Also eben eher linear: Anforderungen umsetzen, Refactoring (Umbau auf neues System), Anforderungen umsetzen, Refactoring - alles in einem Stang. Anhand von Roadmap, IssueTracker, SVN kannst du dich ja auch schon auf die Neuerungen vorbereiten und dich entsprechen ausrichten.

Durch die Tests, die parallel zur Entwicklung durchgeführt werden entsteht aber ein Problem. Man müsste ja ständig nicht nur in den branch commiten, sondern auch der trunk müsste immer auf dem aktuellen Stand sein, um eben Testen zu können, ob die Anwendung läuft.

Warum? In dem Fall hätte jeder Zweig doch seine eigenen Tests (bis auf die Tests der gemeinsamen Code-Basis natürlich).

Da tritt dann das nächste Problem auf. Was macht man, wenn die Anwendung nicht läuft. Fixed man das oder nicht?

Es ist einfach wichtig, dir immer im klaren zu sein, was du gerade machst: Erweiterst du die Anwendun um neue Funktionen oder baust du sie bei gleich bleibender Funktionalität um. Mitten im Umbau auf einem noch nicht wieder komplett lauffähigen System Änderungen zu machen kann kritisch werden, bietet sich mitunter aber auch an.

Eben: Wenn du nicht sicher bist, dass die Portierung klappt bzw. du diese nicht definitiv durchziehen wirst, dann leg einen Branch an und guck, wie weit du damit kommst. Wenn zwischenzeitlich Änderungswünsche kommen, dann hast du im Trunk eine lauffähige Version, die du eben erweitern kannst. Klappt die Portierung dann im Branch, dann bringst duauch dort die Änderungen aus dem Trunk ein und schiebst das alles wieder zurück in den Trunk.

So würd ich es machen - denke ich. So hast du halt im Trunk möglichst immer eine lauffähige Version und kannst dort auch auf neue Anforderungen und Bugs reagieren und im Branch probierst du halt, wie du das Dingens portiert bekommst (bei unveränderterFunktionalität).

Basti