Mercurial Struktur aufbauen (Benötige Hilfe)

[Uwe Raabe]

Zitat von Stevie:

Ich bin kein Mercurial Experte, aber das hört sich irgendwie nicht sehr nach einer sinnvollen Strategie an.

Es lebe die Meinungsvielfalt!

Übrigens: Gerade bei der Zusammenarbeit mit anderen Entwicklern empfinde ich dieses Vorgehen als deutlichen Vorteil. Fällt irgendwie doch auch unter den Begriff "Separation of Concerns", oder?

[Stevie]

Zitat von Uwe Raabe:

Übrigens: Gerade bei der Zusammenarbeit mit anderen Entwicklern empfinde ich dieses Vorgehen als deutlichen Vorteil. Fällt irgendwie doch auch unter den Begriff "Separation of Concerns", oder?

Da es hier ja inzwischen auch um Git geht, kann ich dir sagen, dass man sich mit dem Aufteilen auf 2 Repos keinen Gefallen tut, was das zusammenführen von Dateien angeht (habe selbst gerade das Mergen von 2 unterschiedlichen GIT Repos hinter mir).
Für das gibt es Branche und Tags. Natürlich kann ich mir 2 lokale Repositories auf die beiden Branche machen, wenn ich mir das switchen sparen möchte, aber aus Erfahrung (ich arbeite nun seit über 2 Jahren in einem Team von mehr als 10 Entwicklern mit GIT) kann ich sagen, dass man das eigentlich nicht benötigt. Und SoC ist es sehr wohl, wenn man unterschiedliche Branche oder Tags für unterschiedlichen Versionen anlegt (siehe GIT Flow).
Im übrigen benötigt man auch nicht unterschiedliche Repos für CI, jedes halbwegs taugliche CI kann sich nämlich den Stand holen, den man angibt - sprich mach mir ein Build von Version 1 und eins von Version 2 geht ohne weiteres.

[RWarnecke]

Hallo zusammen,

erstmal danke für die vielen Antworten. Von meinem jetzigen Standpunkt her, sind die letzten Antworten und die enthaltenen Links sehr informativ, wenn ich schon ein bestehende Repositories habe. So habe ich es zumindest verstanden.

Auf zwei Dinge möchte ich nochmal eingehen :

1. Auf die zwei Versionen in den getrennten Verzeichnissen, möchte ich nochmal eingehen. Version 1 wird nur noch mit Bugfixes versorgt und wird fliegen, wenn Version 2 fertig ist. Version 1 kann ich nicht mit Version 2 mergen, da es sich inhaltlich um einen komplett anderen Aufbau in den beiden Versionen handelt. Also wäre nach den ganzen Antworten jetzt meine Meinung, dass ich Version 1 und Version 2 in jeweils ein Repository schiebe und die Versionen auch getrennt behandel.
2. Nun zu den Projekten mit den mehreren Platformen. Wenn alle Platformen zum größten Teil sich den gleichen Quelltext teilen, dann würde ich das Projekt in ein Repository stecken. Gibt es für jede Platform Ihren eigenen Quelltext (z.B. andere Programmiersprache), dann würde ich das Projekt nach Platformen in einzelne Repositories aufteilen.

Macht das Sinn, was ich hier geschrieben habe oder ist das Ganze so brauchbar und nutzbar ? Oder anders gefragt, habe ich eventuell später Probleme, wenn die oben stehenden Punkte so ausführe ?

[Uwe Raabe]

Zitat von RWarnecke:

Macht das Sinn, was ich hier geschrieben habe oder ist das Ganze so brauchbar und nutzbar ? Oder anders gefragt, habe ich eventuell später Probleme, wenn die oben stehenden Punkte so ausführe ?

Ich denke, damit fährst du ganz gut.

[Stevie]

Zitat von RWarnecke:

[*]Nun zu den Projekten mit den mehreren Platformen. Wenn alle Platformen zum größten Teil sich den gleichen Quelltext teilen, dann würde ich das Projekt in ein Repository stecken. Gibt es für jede Platform Ihren eigenen Quelltext (z.B. andere Programmiersprache), dann würde ich das Projekt nach Platformen in einzelne Repositories aufteilen.

Nein, auch wenn sie sich nichts an Source teilen, würde ich sie in dasselbe Repository packen, sonst hast du irgendwann einen Heidenaufwand, um die Entwicklungen für die verschiedenen Plattformen zu verwalten. Denn Änderungen betreffen ja nicht nur eine Plattform sondern u.U. mehrere.
Siehe dazu diese Antwort.

[RWarnecke]

Zitat von Stevie:

Nein, auch wenn sie sich nichts an Source teilen, würde ich sie in dasselbe Repository packen, sonst hast du irgendwann einen Heidenaufwand, um die Entwicklungen für die verschiedenen Plattformen zu verwalten. Denn Änderungen betreffen ja nicht nur eine Plattform sondern u.U. mehrere.
Siehe dazu diese Antwort.

Ok, wenn ich für jede Platform ein Repository anlege, muss in jedem Repository dokumentiert werden. Lege ich das ganze Projekt in einem Repository an, so kann ich mit einem Commit alle Änderungen über alle Platformen dokumentieren. So habe ich die Antwort aus dem Link verstanden. Wenn das so richtig ist, macht das durchaus Sinn.

Ich muss mir das noch Mal durch den Kopf gehen lassen. Irgendwie ist das alles bei mir noch nicht richtig im Kopf angekommen, wie ich Repository-Strukturen aufbaue, bin immer noch in der Verzeichnis-Versions-Welt.

[Sherlock]

Denk halt dran, das Du mit quasi einem Mausclick absolut sauber zu jedem beliebigen Revisionsstand gelangst. Je mehr "physisch" getrennte Repositories (die eigentlich "logisch" zusammengehören) Du dann hast, desto schwieriger wird das. Es gibt Leute, die einfach alles in ein Repository kippen, und damit wunderbar zufrieden sind. Ich finde das etwas... unübersichtlich bis unglücklich. Darum haben wir pro Projekt ein Repository und ein gemeinsames Subrepository für geteilte Units und Komponenten (hast du sowas auch vor?).

Insgesamt hat Uwe absolut Recht es ist Geschmackssache, und so lange man nicht anfängt in der Historie der Repositories rumzupfuschen, kann eigentlich auch nichts kaputt gehen. Ich würde aber wirklich versuchen, jegliche SVN Erinnerungen abzustoßen und mich voll auf die "neuen" Möglichkeiten einzulassen.

@Uwe: Auf dem Server erlauben wir mehrere Heads, weil unser Entwicklungsplan das so vorsieht. Die Branches repräsentieren nunmal die verschiedenen Versionsstände, und werden nach Freigabe einer Version abgeschlossen. Aber bis zur Freigabe (Testen, Dokumentieren, etc.) ist das Projekt ja nicht im Winterschlaf, sondern da wird fleissig weiter entwickelt. Und unter Umständen wird schon an der übernächsten Version gearbeitet, weil eventuell eine Tech-Demo ansteht oder einfach die Spezifikation schon weit genug ist. Da wir zu mehreren an jeweils einem Projekt arbeiten, ist das ohne multiple Heads nicht elegant machbar...und offen gesagt seh ich keinen Grund, warum man die vermeiden sollte.

Sherlock

[RWarnecke]

So, nachdem ich jetzt eine Nach nochmal darüber geschlafen habe, bin ich zu folgendem Entschluss gekommen :

1. Meine bestehenden Projekte, nur für eine Platform oder für mehrere Platformen, werden in jeweils ein Repository gesteckt.
2. Bei dem einen Projekt, wo ich zwei Versionen in jeweils zwei Verzeichnissen pflege, die auch noch unterschiedlich vom internen Aufbau sind, packe ich die Versionen in jeweils ein Repository. Hintergrund dafür ist, dass die Version 1 nur noch mit Bugfoxes versehen wird, bis Version 2 fertig ist und Ihr Release hat.
3. Die eigenen Entwicklungen von Komponeten, die ich auch zum Download anbiete, stecke ich in ein Repository.

Gemeinsam genutzte Units habe ich in meinem Komponenten-Verzeichnis, wo auch die gekauften drin sind. Die leben einfach mit. Da habe ich noch nie auf Versionen geachtet, weil ich eh durch meinen Wartungvertrag jede Delphi-Version mitmache und alles immer auf die neuste Version anhebe.

[Sherlock]

Den letzten Teil hab ich nicht ganz verstanden: Gemeinsame Units versionierst Du mit, oder nicht? Weil da kann es von Version zu Version ja Änderungen geben, die nicht unerhebliche Auswirkungen haben. Wenn Du da also für ein Patch neuere gemeinsame Units verwendest, als in der ursprünglichen Version kann (muss aber nicht) es zu Problemen kommen.

Sherlock

[RWarnecke]

Nein, gemeinsam genutzte Units haben keine Version bei mir, da ich eh ganz wenige davon habe. Die gemeinsamen Units habe ich jetzt seit Delphi 2007 und hatte nur Probleme bei Delphi 2009 (Unicode). Ansonsten haben die Units bis jetzt immer Ihren Dienst getan.

Weshalb sollte ich diese Units in ein Repository stecken, da ich die Projekte und die Units eh immer auf die aktuelle Delphi-Version hebe ?