Ist DVCS (Mercurial) nicht für mich?

Question

Ich arbeite in einem Unternehmen, in dem wir viele kleine kundenspezifische Anwendungen erstellen. Wir sind ein paar Entwickler, aber meistens gibt es nur einen Entwickler pro Projekt.

Customer1 
    ProjectX 
     App 
     Tests 
    ProjectY 
     App 
     Tests 
Customer2 
    Project2 
Products 
    Product1 
Common 

Heute ist alles in einem einzigen Repository gespeichert.

Der Prozess ist einfach.

1. Ein Entwickler nimmt an einem neuen Projekt für einen Kunden
2. für das Projekt einen neuen Ordner erstellen
3. -Code in einem neuen Projekt
4. einige Wartungsarbeiten Sie in einem anderen Projekt
5. Check-in-Updates zur Wartung Projekt
6. Mehr Arbeit in neuem Projekt
7. Check in neuem Projekt
8. Liefern an Kunden

Es gibt keine Markierung oder Verzweigung. Frühere Versionen werden basierend auf dem Datum ausgecheckt.

Dieser Prozess seit vielen Jahren gut serviert, aber es gibt ein paar Schmerzpunkte mit dem aktuellen Werkzeug (CVS)

• Langsam. Der Checkout dauert Minuten, auch wenn sich nichts geändert hat. History wird auf dem Server gespeichert, so dass Diffs zu lange dauert.
• Hinzufügen neuer Projekte. Wenn Sie mit CVS gearbeitet haben, wissen Sie Folgendes: Ordner hinzufügen, Dateien im Ordner hinzufügen, nächsten Ordner hinzufügen ...
• Keine Möglichkeit, offensichtliche Fehler zu beseitigen (Einchecken von Binärdateien usw.)
• Keine Unterstützung für die Umbenennung, die macht notwendige Refactoring noch schmerzhafter.

Ich habe Mercurial privat seit einiger Zeit verwendet und möchte es auf alle Entwickler erweitern.

Ich könnte es alles falsch haben, aber es gibt ein paar Dinge, die ich nicht verstehe, wie in unserer Organisation zu implementieren.

CVS Commits sind nur aktuelle Ordner, aber in mercurial sind sie Repository-weit. In unserem Fall bedeutet dies, dass das Versenden von Wartungsarbeiten in einem Ordner auch noch nicht abgeschlossene Daten in einen anderen Ordner schreibt. (ich nehme an wir hg ci ./** in veränderten Ordner tun könnte, aber das ist nicht auf merge erlaubt, zumindest das ist, was die Dokumentation sagt If you are committing the result of a merge, do not provide any filenames or -I/-X filters.)

Die gängige Praxis in Mercurial ist ein Repository pro Projekt zu haben.

Ein Repository pro Projekt ist für uns in Ordnung, aber es schafft einige andere Fragen wie:

Wie mehrere Repositories auf dem zentralen Server verwalten?
Wenn ein Entwickler ein neues Projekt erstellt, muss er eventuell Änderungen vornehmen. Gerade

hg push http://localhost:8000/Customer1/NewProject

tun stürzt die hg-Webserver mit einem hässlichen Stapelabbild und hängt den Client.

So wie ich es verstehe, ist, dass der Entwickler Zugriff auf die Server-Shell müssen das neue Repository in einer Konfigurationsdatei hinzufügen und neu starten hgweb

Die Alternative ist, SSH oder einen Anteil (sind dort zu verwenden, zugute kommt mit SSH statt einer Dateifreigabe?)

cd Customer\NewProject 
hg init 
hg clone --noupdate --pull . //mercurialshare\Customer\Project 
echo "[paths]" >.hg\hgrc 
echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc 

hg push 

Works, ist aber ein bisschen zu kompliziert für einige Entwickler

Alle Entwickler müssen alle Projekte haben.
(Nicht alle, aber viele Projekte wirklich so sie vorhanden sein müssen verbunden und es ist am einfachsten, alle haben nur)

mit vielen bestehenden Projekte und neue hinzugefügt wöchentlich brauchen wir einen Weg, um alle Projekte in einem ziehen geh und klon auch neue.

Ich dachte, dass subrepos könnte den „global“ Pull aber die folgenden Linie in der Dokumentation ist ein Hemmschuh

„löst Wenn wir begehen, wird Mercurial versuchen, eine konsistente Momentaufnahme des Zustands der gesamten zu erstellen Projekt und seine Subrepos. Es tut dies, indem es zuerst versucht, in allen modifizierten subrepos zu begehen und dann den Zustand aller subrepos aufzeichnet. "

Zurück zu dem Einzel-Repository-Problem der globalen Festschreibungen.

(versucht, ein paar Varianten hg ci .hgsub .hgsubstate <subrepo> aber .hgsubstate scheint nur auf vollen Commits aktualisiert werden. Andere Benutzer werden nicht Projektänderungen ohne explizite hg pull --update im Projektordner sehen)

Mein aktuelles Denken haben, ist ein Batch-Datei in der Wurzel, die alle Projekte zieht

Haben Sie weitere Ideen zur Verwendung von Mercurial in unserer Organisation?

bearbeiten

Danke für die Antwort. Ich evaluiere derzeit, wie ein Repository pro Projekt für uns arbeiten wird. Ich lege eine Batch-Datei auf der obersten Ebene

Answer 1

Ihr Recht zu sagen, dass Mercurial ist für ein Projekt pro Repo ausgelegt. Es ist auch viel schöner, wenn Sie so arbeiten, weil die Geschichte der verschiedenen Projekte getrennt gehalten wird.

Der Versuch, mehrere Projekte in einem DVCS-Repo zu erstellen, verursacht nur Probleme.

Persönlich bevorzuge ich Projekte über SSH statt HTTP zu dienen. Ein Grund dafür ist die Fähigkeit, ...

# hg init blah 
# hg clone blah ssh://server/blah 

Wenn Sie über HTTP sind dient dies nicht funktioniert (wie Sie herausgefunden haben).Ich bin überrascht, dass es aber einen harten Absturz verursacht: -/

Die Sub-Repos-Methode, alle Projekte zu bekommen, ist nicht ganz so, wie Sie es beschreiben. Es ist nicht so, dass Sie wieder zu globalen Commits zurückkehren (Projekte können individuell entwickelt werden), sondern dass das Superprojekt die Version der Subprojekte speichert, von denen es abhängt. Dies ist genau das, was Sie wollen, wenn Sie zum Beispiel eine Bibliothek als Teilprojekt haben, aber das Release hängt von einer bestimmten Version ab. Effektiv ist ein Sub-Repo-Link ein Lesezeichen in einem anderen Repo bei einer bestimmten Version.

Nicht wirklich, wonach Sie aber streben.

Möglicherweise sollte das gemeinsame Zeug ein Unter-Repo der Projekte sein, die es brauchen. Jedes Projekt kann dann auf einer anderen Version desselben Codes eingefroren werden, und Sie haben keine Probleme. Das würde ein wenig darüber nachdenken müssen.

Sonst ist die Skript-Idee wahrscheinlich am einfachsten.