Mercurial Struktur aufbauen (Benötige Hilfe)

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1263805)

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:

Zitat von Uwe Raabe (Beitrag 1263809)

Ü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:

Zitat von RWarnecke (Beitrag 1263844)

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:

Zitat von RWarnecke (Beitrag 1263844)

[*]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:

Zitat von Stevie (Beitrag 1263848)

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 ?

[Sherlock]

Nunja, eventuell unterscheiden sich unsere Definitionen von gemeinsamen Units :D
Wir hier haben gemeinsame Units, in den Produkt-/Projektübergreifend Klassen und Methoden existieren, die das eine oder andere erledigen, was eben alle brauchen. Die unterliegen aber genauso dem Wandel wie die Projekte an sich. Manches mit schlafwandlerischer Sicherheit von Jahr zu Jahr. Es wäre fatal, einen Patch für einen Versionstand aus 2013 mit den Methoden von 2014 zu beheben. Selbst wenn sich keine Änderungen durch den Jahreswechsel ergäben, könnten neue Features eingebaut worden sein, die den Patch-Kunden eben nicht zustehen.

Falls bei Dir gemeinsame Units unveränderlich sind...dann brauchste die freilich nicht zu versionieren...Falls ;)

Sherlock

[RWarnecke]

Zitat:

Zitat von Sherlock (Beitrag 1263952)

Wir hier haben gemeinsame Units, in den Produkt-/Projektübergreifend Klassen und Methoden existieren, die das eine oder andere erledigen, was eben alle brauchen. Die unterliegen aber genauso dem Wandel wie die Projekte an sich. Manches mit schlafwandlerischer Sicherheit von Jahr zu Jahr. Es wäre fatal, einen Patch für einen Versionstand aus 2013 mit den Methoden von 2014 zu beheben. Selbst wenn sich keine Änderungen durch den Jahreswechsel ergäben, könnten neue Features eingebaut worden sein, die den Patch-Kunden eben nicht zustehen.

Hier gebe ich Dir recht, da sollte man die gemeinsamen Units in ein Repository stecken.

Zitat:

Zitat von Sherlock (Beitrag 1263952)

Falls bei Dir gemeinsame Units unveränderlich sind...dann brauchste die freilich nicht zu versionieren...Falls ;)

Unveränderlich nicht. Die Units werden halt der Delphi-Version angepasst. Meine gemeinsamen Unit sind hauptsächlich nur Units, wie zum Beispiel XML-Files auszulesen oder um die Sprache in einem Programm umzustellen. Alle anderen Funktionen, Methoden oder Klassen, die ich immer wieder in Programmen einsetze, habe ich als Code-Snippet und werden in das jeweilige Projekt oder Version reinkopiert und dann individuell den Anforderungen angepasst.

[pertzschc]

Zitat:

Zitat von RWarnecke (Beitrag 1263956)

Zitat:

Zitat von Sherlock (Beitrag 1263952)

Wir hier haben gemeinsame Units, in den Produkt-/Projektübergreifend Klassen und Methoden existieren, die das eine oder andere erledigen, was eben alle brauchen.

Hier gebe ich Dir recht, da sollte man die gemeinsamen Units in ein Repository stecken.

Ein Beispiel bei mir ist der About-Dialog, den alle Programme aus einem gemeinsamen Codelib-Pfad einbinden. Dieser ist in einem sepearaten Repo. Darin befindet sich weiterhin die Unit, welche OS-Versionen ermittelt.

Grüße,
Christoph

[Der schöne Günther]

Ich habe wahnsinnig viel gemeinsam genutzten Code. Es ist in zwei Libraries (=Repos) aufgeteilt:

1. Allgemeingültige Helfer, wie Mathematik, VCL-Helferklassen oder halt Klassen für ganz spezielle Aufgaben wie "Gib mir einen TChart als Vektorgrafik"
2. Problemspezifische Library - Der Kram um den es in so ziemlich jedem Projekt geht. Sagen wir beispielsweise mal "Kram für Maschinen die Schokoladenkekse herstellen. Und alles drum herum". Hier sind die einzelnen Files natürlich auch untereinander abhängig.

Ein Projekt benutzt immer nur eine feste Revision einer Library. So kann jemand an der Library weiterarbeiten, das Projekt kann parallel auch weiter entwickelt werden und bei Bedarf zieht man den Library-Import auf die grade aktuelle Revision hoch.


Hat das jemanden weitergebracht? Wahrscheinlich nicht. Ich fand nur die Unterscheidung von "gemeinsam genutzten Code" in die zwei "Kategorien" wichtig.

[RWarnecke]

Ich glaube es kristallisiert sich eine unterschiedliche Definition von gemeinsam genutzten Quelltext heraus. Ich denk hier, das muss jeder selber wissen, wie er hier seine Repositories aufteilt. Aus meiner Sicht macht alles Sinn, was hier geschrieben wurde, aber es ist auch sicherlich eine Geschmackssache. Ich habe, wie oben geschrieben mehrere Code-Snippets in einer Datenbank. Diese verwende ich ganz individuell in jedem Projekt. Ich habe hiermit sozusagen die Versionierung von den gemeinsamgenutzten Klassen und Methoden in meine Datenbank gelegt. Was ich aus meiner Sicht und vom Geschmack her viel flexibler finde.

Und bekanntlich lässt sich über Geschmack ja streiten ;-)

[sh17]

Also bis auf das Delphi selbst steckt bei uns alles im Repository, selbst die Komponenten von Drittherstellern. So kann ich ein komplettes Entwicklungssystem einer älteren Version auschecken, mit einem kleinen Tool die Komponentenregistrierung im Delphi angepasst und das alte System läuft wieder. Macht leider manchmal bei Komponentenupdates etwas Arbeit die sich selbst installierenden Komponenten aus den allgemeinen Pfaden wieder rauszubasteln und in den eigenen Quellcodepfad wieder einzubauen, geht aber leider nicht anders.
Selbst die mitgelieferten Indys hau ich aus dem Delphi raus und kompiliere die aktuellen Quellen neu.

Von daher steckt immer alles was zu einem Projekt gehört mit in dem Repository. Wenn ich z.B. Indy in zwei Repos benötige, werden sie doppelt gepflegt. Es gibt kein gemeinsames Repository. Meiner Meinung nach der Beste Lösung.

[Namenloser]

Zitat:

Zitat von sh17 (Beitrag 1263975)

Von daher steckt immer alles was zu einem Projekt gehört mit in dem Repository. Wenn ich z.B. Indy in zwei Repos benötige, werden sie doppelt gepflegt. Es gibt kein gemeinsames Repository. Meiner Meinung nach der Beste Lösung.

Sub-Repositories sind da bei Mercurial eine interessante Option. Man kann so z.B. ein zentrales Indy-Repository haben, packt dieses aber NICHT in den Suchpfad. Stattdessen erstellt für jedes Projekt, das Indy verwendet, im Projektordner ein Subrepository und pullt regelmäßig die neuen Versionen vom Haupt-Indy-Repository. Der Clou ist, dass wenn man das Projekt commitet, auch der Versionsstand des Sub-Repositories mitversioniert wird. D.h. wenn man auf eine alte Version zurückgeht, dann ist auch das Sub-Repository wieder auf dem damaligen Stand.

Ich versuche das bei neuen Projekten konsequent so zu machen.

Man sollte allerdings ein paar Dinge beachten.

[Der schöne Günther]

Das scheint ja genau das zu sein was man unter Subversion als

Delphi-Quellcode:

externals

-Property kennt. Ich glaube ich werde mich nicht davor fürchten müssen, eines Tages umzusteigen.

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1264032)

Das scheint ja genau das zu sein was man unter Subversion als

Delphi-Quellcode:

externals

-Property kennt. Ich glaube ich werde mich nicht davor fürchten müssen, eines Tages umzusteigen.

Ich komme mit den Subrepos von Mercurial wesentlich besser zurecht als mit den SVN-Externals. Seit dem Schreiben dieses Beipackzettels sind auch schon einige Versionen ins Land gegangen. Das Umdenken von einem zentralen zu einem dezentralen System ist die eigentliche Herausforderung.

[sh17]

Zitat:

Zitat von Uwe Raabe (Beitrag 1264038)

Das Umdenken von einem zentralen zu einem dezentralen System ist die eigentliche Herausforderung.

Das merke ich - :(

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1262042)

Gibt es eventuell Interessenten für einen diesbezüglichen Vortrag bei den Delphi-Tagen? Ich könnte da vielleicht ein paar Worte drüber verlieren. Vielleicht wäre aber auch ein etwas ausführlicherer Workshop interessant?

Hallo-

Gibt es mittlerweile Neuigkeiten? Wie realistisch ist zumindest ein Vortrag geworden?

[Phoenix]

Ich hab zumindest mal ne Session eingereicht.
Das liegt jetzt an den Verantwortlichen für das Programm, ob das auch stattfindet oder nicht :wink:

[Daniel]

Wir sind gerade dabei, die Agenda zu fixieren.
Bis spätestens Samstagmittag soll das erledigt sein (weil ich dann erstmal im Urlaub sein werde und meine Privatyacht bedauerlicherweise noch kein brauchbares Internet hat. Möglicherweise werden wir die Datenpakete per Helikopter an Land fliegen lassen müssen).

Ich bin sicher, dass das Thema in der Agenda vertreten sein wird.

[SvB]

@RWarnecke: welchen Git-Server hast Du benutzt und unter welchem Betriebssystem? Würde mich abschließend zu dem sehr hilfreichen Beitrag noch interessieren.

Danke

[RWarnecke]

Hallo Sven,

ich benutze einen Ubuntu 14.02 Linux Server, wo ich Git drauf installiert habe. Mit dem Git Client auf meinem Mac wird das Repository dann vom Mac auf den Linux Server übertragen.