Ich gehe mit den "Liebes Tagebuch, meine ersten Schritte in Mercurial" wahrscheinlich allen auf den Geist, bislang hat mich aber noch niemand hart genug beschimpft.

Wir wollen ein Subversion-Repo komplett von Subversion auf Mercurial bringen. Aus Delphi/C++-Builder-Sicht enthält es mehrere Projekte, die gehören aber alle zusammen. Jedes dieser Projekte benutzt externe Libraries aus anderen SVN-Repos.

Es sieht so aus:

markieren

Code:

[Main]
   doc
   Core
      src
      (Lib1)
      (Lib2)
   Proj2
      src
      (Lib2)
   Proj3
      src
      (Lib1)
      (Lib3)

Wobei gilt: [Repo] und (über svn:externals eingebundenes Repo).
In Subversion war das bislang eigentlich komfortabelst zu handhaben.


Ich bin ratlos, wie man das in HG umsetzen sollte:

• 1:1-Umsetzung: Dann hätte ich einen Haufen direkter Subrepos wie "Lib1_für_Proj3", "Lib1_für_Core"
• Die Projekte auch zu einzelnen Repos machen
• Die Projekte zu einzelnen Repos machen, und diese wieder in einem "Master-Repo" verpacken

Letzteres sähe dann so aus:

markieren

Code:

[Main]
   doc
   [Core]      
      src
      [Lib1]
      [Lib2]
   [Proj2]
      src
      [Lib2]
   [Proj3]
      src
      [Lib1]
      [Lib3]

Das funktioniert erwartungsgemäß, mich stören hier allerdings zwei Dinge:

1. Aus unerfindlichen Gründen dauert das Klonen von "Main" über Gigabit-Netzwerk mehrere Minuten. Auf der Platte landen dabei 40MB. Über Subversion war das eine Angelegenheit von fünf Sekunden.
2. Wenn ich an "Core" etwas ändere muss ich jedes mal auch auf "Main" die Änderungen durchschleifen, also auf eine neuere Revision des "Core"-Subrepos upgraden. Beim pushen muss ich jedes mal "Main" und "Core" an den Server pushen.

Daher zwei Fragen:

1. Was wäre eurer Meinung nach die beste Aufteilung? Technisch gesehen sind die einzelnen Projekte alleine lauffähig, machen inhaltlich allein aber kaum Sinn.
2. Kann man in TortoiseHG das "Über-Repo" automatisch aktualisieren lassen wenn man im Subrepo comittet?

Zitat von Der schöne Günther:

[*]Aus unerfindlichen Gründen dauert das Klonen von "Main" über Gigabit-Netzwerk mehrere Minuten. Auf der Platte landen dabei 40MB. Über Subversion war das eine Angelegenheit von fünf Sekunden.

Das liegt wohl daran, dass bei HG, dadurch dass jeder Klon wieder ein vollwertiges Repository ist, auch die ganze History übertragen werden muss, also alle Zwischenversionen seit dem 1. Commit, während es bei Subversion nur die letzte Version ist.

Schau dir mal die GuestRepo-Extension für Mercurial an. Aus dem praktischen Einsatz kann ich leider noch nichts berichten, aber von der Beschreibung her sollte es die Nachteile der Subrepos für genau diesen Anwendungsfall aufheben. Mir war das Projekt bei den Recherchen zu meinem Vortrag aufgefallen, aber ich konnte es noch nicht eingehend evaluieren.

Das auf den ersten Blick hervorstechendste Merkmal ist die Möglichkeit Tags und Branches anstatt lediglich ChangeSets anzugeben. Damit kann man sich z.B. immer auf den Tip eines Branches beziehen, was dann das ständige Anpassen des Master-Repos obsolet macht.

Den Grund für die benötigte Zeit sehe ich ein. Aber sooo lange?

Die Beschreibung der GuestRepos liest sich exzellent. Das könnte genau das sein, wonach ich suche...

Zitat von Der schöne Günther:

Den Grund für die benötigte Zeit sehe ich ein. Aber sooo lange?

Das sehe ich auch so. Die Zeit ist deutlich zu lang. Es kommt natürlich immer auf das Repo an, aber die "mehreren Minuten" kommen mir doch merkwürdig vor. Insbesondere, da beim Clone ja eine komprimierte Übertragung erfolgt, sollte das nicht so viel länger dauern. Ist aber so von Weitem recht schwierig, die Ursache für diese Verzögerung zu analysieren.

Mehrere Minuten sind definitv zu lang, wenn da nur Sourcen übertragen werden. Sollten da Exen und Zips im Repo liegen hast du ein grundsätzliches Verständnisproblem. Ich würde im übrigen aus jedem Projekt ein Repo und aus den Libs1..n ein einziges Subrepo machen, in dem alle vorgennanten Ordner liegen. Wir handhaben das jetzt seit knapp drei Jahren so und fahren sehr gut damit.

Sherlock

Zitat von Sherlock:

Sollten da Exen und Zips im Repo liegen hast du ein grundsätzliches Verständnisproblem.

Keine Bange, nur Sourcecode. Die Größe kommt einmal daher dass die gleiche Library mehrmals als Subrepo in den verschiedenen Projekten vorkommen und vielleicht ein paar Icons in den DFMs.

Zitat von Sherlock:

Libs1..n ein einziges Subrepo machen

Warum sollte man das tun? Das ergäbe ein "TeeChart, Mathematische Superberechnungen, IMC-Library und mehr"-Repository.

Zitat:

Zitat von Sherlock:

Libs1..n ein einziges Subrepo machen

Warum sollte man das tun? Das ergäbe ein "TeeChart, Mathematische Superberechnungen, IMC-Library und mehr"-Repository.

Ich hoffe mal, das war anders gemeint. Es macht nämlich überhaupt keinen Sinn, mehrere Bibliotheken in ein Repo zu packen. Was ich daraus verstanden hatte: Ein Verzeichnis mit allen Libs als eigene Subrepos - etwa so (Subrepos in runden Klammern):

markieren

Delphi-Quellcode:

[Main]
   (doc)
   lib
      (Lib1)
      (Lib2)
      (Lib3)
   (Core)
   (Proj2)
   (Proj3)

So in der Art hatte ich das auf der letzten Folie in meinem Vortrag auch dargestellt. Wenn die einzelnen Teilprojekte nicht wirklich unterschiedliche Versionen der Libs brauchen, ist diese Struktur etwas schlanker.

Ja, das ist etwas eleganter. Bei mir benutzen die Projekte momentan leider unterschiedliche Versionen der Libs, aber ändern ließe sich das sicherlich.

Die Gedanken werde ich mir wahrscheinlich nicht mehr machen, denn die "Guest Repo"-Erweiterung tut eigentlich genau was ich will:

• Einfach zu bedienen
• Klonen des Repos funktioniert auch wenn die externen Libraries nicht erreichbar sind
• Verändert nichts am typischen HG-Arbeitsablauf
• Kann subrepos in "guest repos" konvertieren

Für mich ist das wohl die perfekte Lösung- An den Libraries wird eh nichts "lokal" verändert, die ganze "Subrepo"-Geschichte hat das alles irgendwie komplizierter gemacht als sein musste.

Zitat von Uwe Raabe:

Ich hoffe mal, das war anders gemeint. Es macht nämlich überhaupt keinen Sinn, mehrere Bibliotheken in ein Repo zu packen. Was ich daraus verstanden hatte: Ein Verzeichnis mit allen Libs als eigene Subrepos

Ja, so meinte ich das. War nur schon Feierabend, und ich postete quasi im Weggehen...

Sherlock