Mercurial Struktur aufbauen (Benötige Hilfe)

[Sherlock]

Nunja, eventuell unterscheiden sich unsere Definitionen von gemeinsamen Units
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 von Sherlock:

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 von Sherlock:

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 von RWarnecke:

Zitat von Sherlock:

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 von sh17:

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 externals -Property kennt. Ich glaube ich werde mich nicht davor fürchten müssen, eines Tages umzusteigen.

[Uwe Raabe]

Zitat von Der schöne Günther:

Das scheint ja genau das zu sein was man unter Subversion als 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 von Uwe Raabe:

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

Das merke ich -