Ich bin ein Subversion-Benutzer, und ich denke, dass ich jetzt hauptsächlich mit meinem Kopf herumkomme. Natürlich denken wir jetzt darüber nach, zu Mercurial zu wechseln, und ich muss neu anfangen.
In unserem einzigen Repository haben wir das typische branches , tags , trunk Layout. Wenn ich einen Feature-Zweig erstellen möchte:
trunk nach branches/Features/[FeatureName] . branches/Features/[FeatureName] . trunk einbinden, Konflikte lösen und committen. trunk , dann "Reintegriere" den Feature-Zweig in trunk. (Bitte beachten Sie, dass dieser Prozess vereinfacht ist, da er Verzweigungen von Release-Kandidaten usw. nicht berücksichtigt.)
Ich habe also Fragen dazu, wie ich in Mercurial die gleichen Anforderungen erfüllen würde (d. h. Feature-Branches anstatt an Trunk zu arbeiten):
In Mercurial ist noch ein Zweig drin das Repository, oder ist es ein ganz neues lokales Repository?
Das Äquivalent der Subversion-Arbeitsweise wäre ein Repository mit mehreren Köpfen in mercurial. Dies ist jedoch nicht der idiomatische Weg, Dinge zu tun. Normalerweise haben Sie nur einen Kopf in einem gegebenen Repository, also separate Repositories für jeden Zweig.
Wenn wir alle eine Kopie des Ganzen haben Repository, heißt das, dass wir alle haben Kopien der verschiedenen Funktionen des jeweils anderen Zweige (das ist eine Menge Daten Transfer)?
Ja, wenn Sie sich den Verlauf des Kopfs Ihres lokalen Repositorys ansehen, können Sie alle Feature-Zweige sehen, in denen sie zusammengeführt wurden. Aber mercuriale Repositories sind bemerkenswert platzsparend. Zum Beispiel habe ich ein hg clone https://www.mercurial-scm.org/repo/hg gemacht, um die Quelle für Mercurial selbst zu bekommen, und es ist nur 34.3 MB auf einem NTFS-Dateisystem (im Vergleich zu dem Quellcode herunterladen , was 1,8 MB ist). Mercurial wird auch Hardlinks verwenden, wenn Ihr Dateisystem dies unterstützt, so dass ein geringer Aufwand entsteht, wenn Sie ein Repository an einen anderen Speicherort auf dem gleichen Datenträger klonen.
Ich weiß, Mercurial ist ein DCVS, tut es aber Das heißt, wir ziehen Änderungen von einander direkt, anstatt über a Peer-Repository auf einem Server?
Eine Möglichkeit besteht darin, dass jeder Entwickler ein öffentliches Repository zur Verfügung stellt, in dem er seine eigenen Änderungen vornimmt. Alle anderen Entwickler können dann ziehen, was sie wollen.
Normalerweise haben Sie jedoch ein oder mehrere "gesegnete" Repositories, in denen alle Änderungen integriert sind. Alle Entwickler müssen dann nur aus dem gesegneten Repository ziehen. Selbst wenn Sie nicht explizit ein so gesegnetes Repository haben, stelle ich mir vor, dass sich die Leute automatisch so organisieren würden, z. indem alle von einem führenden Entwickler gezogen werden.
Steve Loshs Artikel über die Verzweigung in mercurial, der oben verlinkt ist, ist fantastisch. Ich bin auch in einige Erklärungen der Verzweigung und wie die DAG in eine Präsentation, die ich gab vor ein paar Monaten auf mercurial, das ist auf Slideshare . Die relevanten Folien beginnen bei Folie 43.
Ich denke, dass das Verständnis, dass alle Commits zum selben Repository in einem DAG (Directed Azyklic Graph) mit einigen einfachen Regeln gespeichert sind, wirklich hilft, das zu entmystifizieren, was vor sich geht.
Benannte Zweige sind eigentlich nur Metadatenbeschriftungen bei Commits, unterscheiden sich aber in Wirklichkeit nicht von anonymen Verzweigungen, die beim Zusammenführen von Personen auftreten, die in Ihrem Repository arbeiten, oder wenn Sie zu einer früheren Version zurückkehren und dann einen Commit durchführen dort um einen neuen Kopf zu machen (den man später zusammenführen kann).