Mercurial Struktur aufbauen (Benötige Hilfe)

[himitsu]

Zitat von RWarnecke:

Meine Frage ist, trennt Ihr die Repositories in die einzelnen Plattformen oder habt Ihr immer nur ein Repository für das ganze Projekt (alle Platformen) ?

Gemeinsame Codeteile in ein eigenes weiteres Repository?

Wenn die gemeinsamen Codes einen großen Anteil haben (was vermutlich so sein sollte), dann macht es sich besser, alles in Eines zu machen.

Zitat von RWarnecke:

Ich habe ein Projekt, wo ich über zwei Verzeichnisse zwei unterschiedliche Versionen pflege. Würdet Ihr hier aus ein Repository oder zwei machen ?

Wenn die Projekte stark getrennt sind, dann Beides in jeweils was Eigenes und dann hast du besseren Überblick welche Codes von einem Projekt in das Andere übergegen.



Also das ist jetzt einfach so meine naive Meinung/Vorstellung.

[Sherlock]

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Sherlock

[RWarnecke]

Zitat von Sherlock:

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Das mit den Branches habe ich gelesen, dass man die für unterschiedliche Versionen nutzt. Wie würdest Du ein Repository erstellen, wo Du zwei unterschiedliche Versionen in zwei unterschiedlichen Verzeichnissen gepflegt hast ?

[Uwe Raabe]

Zitat von Sherlock:

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Das sind halt zwei unterschiedliche Verfahren: Versioning by Branching und Versioning by Cloning. Ich persönlich bevorzuge auch das Versioning by Cloning. Es hält die Repositories übersichtlicher und reduziert den Merging-Aufwand erheblich. Man hat dann halt noch eine übergeordnete Stuktur der voneinander abhängenden Repositories, die man im Auge behalten muss. Durch diese Trennung wird aber m.E. die Übersichtlichkeit des Gesamtsystem deutlich erhöht.

Es mag allerdings durchaus Szenarien geben, wo die andere Vorgehensweise besser geeignet ist. In vielen Fällen ist es auch einfach nur eine Geschmacksfrage.

[Sherlock]

Zitat von RWarnecke:

Zitat von Sherlock:

Für unterschiedliche Versionen gibts doch Branches. Wozu dann komplett getrennte Repositories führen?

Das mit den Branches habe ich gelesen, dass man die für unterschiedliche Versionen nutzt. Wie würdest Du ein Repository erstellen, wo Du zwei unterschiedliche Versionen in zwei unterschiedlichen Verzeichnissen gepflegt hast ?

Du musst Dir vor Augen halten, das eine Revision eines Repositories einen kompletten Dateibestand (zur Entwicklung nötige Dateien freilich) wiederspiegelt (samt den dorthin führenden Changesets). Eigentlich kennen sich zwei verschiedene Versionsbranches nicht. Erst durch Merges (die ja nötig sind, um Änderungen, die beide Versionen betreffen sollen, zu propagieren) gibt es eine Verbindung zwischen den Branches (abgesehen vom gemeinsamen Elternteil). Die unterschiedlich benannten Ordner sind dadurch nicht nötig, sogar kontraproduktiv. Man sollte sich bei "modernen" Versionsverwaltungen vom Konzept der "Versionierung durch Ordner" wirklich verabschieden.

Die Branches koexistieren dann ganz friedlich, bis sie eben abgeschlossen werden und/oder zu neuen Branches führen (siehe den kleinen Auszug aus dem Baum eines Projekts meiner Firma - jede Farbe ist ein benannter Branch).

Sherlock

[RWarnecke]

Hallo Uwe, Hallo Sherlock,

danke erstmal für eure Antworten. Ich bin ja am Aufbau der Repositories für meine Projekte. Wenn ich das ganze jetzt richtig verstanden habe, wäre es sinnvoll jede gepflegte Version, die sich gerade in einem separaten Verzeichnis befindet, in ein einzelnes Repository zu stecken. Was ist eure Meinung bezüglich den Platformen ? Jede Platform ein Repository oder alle Platformen in ein Repository ?

[himitsu]

Nunja, da es ja aktuell schon 2 getrennte Programme/Versionen sind und wenn diese sich schon "stark" unterscheiden, dann kann einem schon die Idee kommen, das auch weiterhin als getrennte Programme anzusehen und demnach auch einzeln zu versionieren.

Wenn man Beides nun getrennt in ein Repository aufnimmt, dann bleiben diese Versionen dennoch "physisch" getrennt.


Was aber auch ginge -> Beides wieder zusammenzumergen.
* für alte Version ein Repository erstellen
* davon/darin einen Branch für die neue Verion erstellen (erstmal ohne Dateien, sondern nur die alte Version branchen)
* die Dateien des neuen Branches durch die Dateien der neueren Version ersetzen und die Ändernungen einchecken
Dann hat man doch erstmal wieder 2 Branches, welche ihre aktuellen Änderungen kennen. Man kann ab da nach herzens Lust hin- und hermergen und vorallem sieht man die Unterschiede auch richtig.

[Uwe Raabe]

Einen bestehenden Multi-Versionsstand zu übernehmen kann schon mal schwierig werden, wenn man die gemeinsame Historie nicht so einfach übernehmen kann. Insofern setzt eine Aussage zur Übernahme natürlich eine gründliche Analyse des bestehenden Umfelds unter Berücksichtigung der bisherigen Versionsverwaltung voraus. Ich könnte mich da jetzt so nicht festlegen.

Im laufenden Betrieb gehe ich (mit Mercurial) bei neuen Versionen immer so vor, daß ich irgendwann einen Clone des Repos für die neue Version anlege und fortan in (mindestens) zwei Repos arbeite. Die neue Version bekommt deshalb schon ein neues Repo, damit die gesamte Build-Struktur für die alte Version unverändert weiterarbeiten kann (schließlich ist es zu diesem Zeitpunkt noch eine Weile hin bis zum Release der neuen Version). Kommt dann die neue Version raus laufen beide Systeme parallel weiter bis die alte Version eingestellt wird.

Die Repos sind durch ihre gemeinsame Versionshistorie ja immer noch verbunden und es lassen sich auch weiterhin noch Bugfixes aus der alten Version in die neue mergen, solange nicht massive Strukturänderungen dies erschweren. Insofern verliere ich durch die getrennten Repos keine Funktionalität, die ich mit Branches innerhalb eines Repos hätte. Es erhöht meiner Meinung aber deutlich die Übersicht. Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!). In meinen Repos entstehen solche Verzweigungen fast ausschließlich durch Implementierung von Features, das Beheben von Bugs oder das Tagging des Build-Systems - und sie werden immer lokal aufgelöst. Auf den zentralen Server-Repos gibt es keine multiple heads.

[himitsu]

Zitat von Uwe Raabe:

Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!).

Wenn du nicht zu Tode erschrecken willst, dann schau dir das besser nicht beim Firefox an (mit den Features und den großen Clonen, wird as ein hübscher "Baum")

[Stevie]

Zitat von Uwe Raabe:

Im laufenden Betrieb gehe ich (mit Mercurial) bei neuen Versionen immer so vor, daß ich irgendwann einen Clone des Repos für die neue Version anlege und fortan in (mindestens) zwei Repos arbeite. Die neue Version bekommt deshalb schon ein neues Repo, damit die gesamte Build-Struktur für die alte Version unverändert weiterarbeiten kann (schließlich ist es zu diesem Zeitpunkt noch eine Weile hin bis zum Release der neuen Version). Kommt dann die neue Version raus laufen beide Systeme parallel weiter bis die alte Version eingestellt wird.

Die Repos sind durch ihre gemeinsame Versionshistorie ja immer noch verbunden und es lassen sich auch weiterhin noch Bugfixes aus der alten Version in die neue mergen, solange nicht massive Strukturänderungen dies erschweren. Insofern verliere ich durch die getrennten Repos keine Funktionalität, die ich mit Branches innerhalb eines Repos hätte. Es erhöht meiner Meinung aber deutlich die Übersicht. Sherlock's Grafik empfinde ich in diesem Zusammenhang auch eher als abschreckendes Beispiel (@Sherlock: no offence!). In meinen Repos entstehen solche Verzweigungen fast ausschließlich durch Implementierung von Features, das Beheben von Bugs oder das Tagging des Build-Systems - und sie werden immer lokal aufgelöst. Auf den zentralen Server-Repos gibt es keine multiple heads.

Ich bin kein Mercurial Experte, aber das hört sich irgendwie nicht sehr nach einer sinnvollen Strategie an. Für sowas gibts doch Branches und Tags.
Du scheinst auch nur allein mit dem VCS zu arbeiten, sonst würd dich so einen Commit Graph ziemlich kalt lassen, da hab ich schon wilderes gesehen.
Außerdem gibt's immer die Anzeigeoption "only current branch".

Da sich ja inzwischen für Git entschieden wurde, werf ich einfach mal ein Stichwort in den Raum: Git flow