Mercurial Struktur aufbauen (Benötige Hilfe)

[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 ?

[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.