Wir erwägen einen Wechsel von SVN zu einem verteilten VCS an meinem Arbeitsplatz.
Ich kenne alle Gründe, warum man ein DVCS für die tägliche Entwicklung verwenden möchte: Lokale Versionierung, einfachere Zweige und Zusammenführungen usw., aber ich habe nicht viel überzeugendes gesehen, was das Verwalten von Softwareveröffentlichungen betrifft. Hier ist unser Veröffentlichungsprozess:
- Feststellen, welche Änderungen zum Zusammenführen verfügbar sind.
- Führen Sie eine Abfrage aus, um die Fehler/Tickets zu finden, die mit diesen Änderungen verbunden sind.
- Filtern Sie Änderungen heraus, die mit "offenen" Tickets verbunden sind. In unserer Umgebung müssen Tickets in einem geschlossenen Zustand sein, um mit einem Veröffentlichungszweig zusammengeführt zu werden.
- Filtern Sie Änderungen heraus, die wir nicht im Veröffentlichungszweig haben möchten. Wir sind sehr konservativ, wenn es darum geht, Änderungen zusammenzuführen. Wenn eine Änderung nicht unbedingt erforderlich ist, wird sie nicht zusammengeführt.
- Führen Sie verfügbare Änderungen zusammen, vorzugsweise in chronologischer Reihenfolge. Wir gruppieren Änderungen zusammen, wenn sie mit demselben Ticket verbunden sind.
- Blockieren Sie unerwünschte Änderungen aus dem Veröffentlichungszweig (
svnmerge block), damit wir nicht erneut damit umgehen müssen.
Manchmal jonglieren wir mit 3-5 verschiedenen Meilensteinen gleichzeitig. Einige Meilensteine haben sehr unterschiedliche Einschränkungen, und die Blockierliste kann ziemlich lang werden.
Ich habe mit git, mercurial und plastic experimentiert, und soweit ich das beurteilen kann, bewältigen sie dieses Modell nicht besonders gut. Es scheint, als würden sie sehr gut funktionieren, wenn man nur ein Produkt veröffentlicht, aber ich kann mir nicht vorstellen, sie für das Jonglieren mit mehreren, sehr unterschiedlichen Produkten aus demselben Codebereich zu verwenden.
Beispielsweise scheint das Herauspicken in mercurial eine Nebensache zu sein. (Sie müssen die 'transplant'-Erweiterung verwenden, die standardmäßig deaktiviert ist). Nachdem Sie eine Änderung in einen Zweig herausgepickt haben, wird sie immer noch als verfügbare Integration angezeigt. Das Herauspicken bricht die Arbeitsweise von mercurial.
Ein DVCS scheint besser für Feature-Zweige geeignet zu sein. Es ist kein Herauspicken erforderlich, wenn Sie direkt von einem Feature-Zweig auf den Stamm und auf den Veröffentlichungszweig zusammenführen. Aber wer möchte die ganze Zeit all diese Zusammenführungen machen? Und wie fragen Sie ab, was zum Zusammenführen verfügbar ist? Und wie stellen Sie sicher, dass alle Änderungen in einem Feature-Zweig zusammengehören? Das klingt nach totalem Chaos.
Ich bin hin- und hergerissen, weil der Programmierer in mir ein DVCS für die tägliche Arbeit haben möchte. Ich will es wirklich. Aber ich fürchte den Tag, an dem ich den Verwaltungshut aufsetzen muss und entscheiden muss, was zusammengeführt werden muss und was nicht. Ich will Code schreiben, ich will kein Zusammenführungsaffe sein.
