Mercurial-Repository-Layout für mehrere Zweige

Question

Ich habe eine Reihe von ähnlichen Projekten, die ich versionssteuern möchte. In SVN würde ich sie einrichten, wie mehrere Verzeichnisse in einem einzigen Projekt

/scripts #updates in sync with project1 & project2 
/project1 #requires database 
/project2 #requires database 
/database 

natürlich anderes SVN-Layout möglich für dieses Spielzeug Beispiel ist, aber das Layout hat Vorteile:

• ich Kopieren von Dateien zwischen den Zweigen kann unter Beibehaltung der Geschichte
• Ich kann nur eine Teilmenge von Projekten auschecken, z. B. svn co repo/project2; svn co repo/database. Dies spart eine beträchtliche Menge an Speicherplatz & Zeit, wenn Projekt1 groß ist.
• Einfache Repository-Management, da Benutzer den Zugriff einmal für alle Projekte definiert

Dieses Paradigma Karte nicht gut, da you can't clone a single directory of a mercurial repo mercurial. Meine Frage ist also: Was ist die gängigste Art, große, eng verwandte Projekte in mercurial zu speichern?

Meine Ideen:

• Mehrere Repositorys - verlieren Geschichte von Dateien, die
• Forests zwischen Projekten bewegen - zum Stillstand gekommen zu sein scheint, und ich bin nicht sicher, wie stabil diese Erweiterung
• Named Zweige mit meist ist nicht zusammenhängender Inhalt
• SubRepos - Leider bin ich Ubuntu 9.04, die nur hg 1.1.2. Sonst würde dies wie eine gute Option aussehen

Answer 1

Mehrere Repositories, Wälder und SubRepos sind alle Varianten auf der gleichen Idee. Forests und SubRepos vereinfachen die Verwaltung von Projekten, die auch sehr aktuelle Versionen anderer Projekte verwenden. Sie lösen nicht das grundlegende Problem, das Sie haben, nämlich dass Sie den Dateiverlauf verlieren, wenn Sie sie zwischen Projekten verschieben.

Meiner Meinung nach ist es das Beste, alle Verzeichnisse im selben Repository abzulegen und darauf zu warten, dass die Mercurial-Funktion das Auschecken von Unterverzeichnissen zulässt. Das Unterverzeichnis-Feature ist eines, um das sich das Mercurial-Team kümmert, aber es ist auch nicht trivial, weshalb es noch nicht gemacht wurde. Ich kenne jedoch die Mercurial Interna, und es ist definitiv machbar, nur eine Menge Arbeit.

Die zweitbeste Option, obwohl ich es wirklich hässlich finde, ist die genannte Idee, die du erwähnt hast. Sie werden immer noch eine sehr seltsame Zusammenführungsoperation ausführen müssen, wenn Sie Dateien zwischen Zweigen kopieren möchten.Sie werden diese Schritte durchführen:

1. Update Leiter der Niederlassung Sie die Datei in kopieren möchten: hg update -C project1
2. Merge in der Branche wollen Sie die Datei kopieren: HGMERGE=/bin/false hg merge -r project2
3. Revert auf den Kopf der Branche wollen Sie die Datei in kopieren: hg revert -a --no-backup -r project1
4. Revert die spezifische Datei, die Sie aus dem Kopf Revision der in Zweig verschmolzen kopieren möchten: hg revert --no-backup -r project2 path/to/file/in/project2.txt die Datei in seinen Platz in der Branche Sie kopieren möchten
5. verschieben es zu: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
6. Markieren Sie die Zusammenführung als aufgelöst: hg resolve -am
7. Und schließlich das Ergebnis begehen: hg commit -m "A merge to copy project2.txt to project1."

Wie gesagt, sehr hässlich. Und es könnte gut nur in hg 1.3 gut funktionieren, da ich weiß, dass einige wichtige Bugs in der Interaktion von Zurückkehren, Zusammenführen und Auflösen vor relativ kurzer Zeit behoben wurden. (IMHO, ich vermute, Ubuntu ist absichtlich auf Versionen von Nicht-bzr Versionskontrollsysteme.)

Wie oft erwarten Sie wirklich, Dateien zwischen Projekten zu kopieren? Warum würde es passieren? Sind Sie sicher, dass das Verlieren von Geschichte so schlimm wäre?

Ich habe etwas Ähnliches in Subversion für ein paar eigene Projekte gemacht, aber meine Erfahrung ist, dass mein anfängliches Gefühl, zu welchem ​​Projekt etwas wirklich gehörte, in der Regel korrekt war und wenn es nicht die Geschichte bewahrte. t wirklich so ein großes Geschäft, da die Geschichte wirklich nur für das ursprüngliche Projekt relevant war, in dem die Datei sowieso war.