Feature-Zweige in CVS?

Question

Ich bin durch die Richtlinien dazu verpflichtet, CVS in diesem bestimmten Projekt zu verwenden. Auch wenn ich eigentlich zu etwas anderem wie Git wechseln würde, kann ich das nicht.

Meine eigentliche Frage lautet also so:Wir haben die Konvention, dass wir jedes Mal, wenn wir eine Veröffentlichung machen, einen neuen Zweig in CVS erstellen (wir taggen auch, aber das ist nicht der Punkt).Wir nennen diese Versionszweige und sie ermöglichen es uns, einfach eine bestimmte Version auszuchecken und Hotfix-Änderungen daran vorzunehmen – das sind unsere Nebenversionen.

Aber jetzt stehen einige große, risikobehaftete Änderungen an, und wenn ich in Git arbeiten würde, würde ich im Handumdrehen einen Feature-Zweig erstellen.Als ich jedoch in CVS arbeitete, versuchte ich, Feature-Branches in einem anderen Projekt zu erstellen, und stellte fest, dass die Dinge schnell chaotisch wurden.Am Ende hatte ich viele Zweige und verlor den Überblick darüber, welche Zweige synchronisiert wurden, welche zusammengeführt werden mussten und welche nicht mehr verwendet wurden.

Wenn wir uns also dem Fragezeichen nähern: Ist es möglich, Feature-Branches in CVS zu verwenden?Sind sie zu aufwändig, als dass sie sich lohnen würden, oder werde ich es irgendwann bereuen, wenn ich sie nicht benutze?Sollte ich in den sauren Apfel beißen und einfach mit dem Codieren in HEAD beginnen, aber meinen Codierungsprozess anpassen, um die Änderungen so unauffällig wie möglich einzuführen?

Answer 1

Wenn Sie die einzige Entwicklung auf dem Feature-Zweig sind, können Sie einfach Git als „Sandbox Entwicklung“ System verwenden und dann, wenn Sie die Änderungen gemacht haben, verschmelzen sie zu Ihrer CVS-Repository.

Sie immer noch den Vorteil der Quellcodeverwaltung gewinnen für Ihr Zwischenarbeitsprodukt.

Answer 2

Es gibt eine ausgezeichnete Diskussion Verzweigungsstrategien genannt gestreamt Linien die helfen könnten -. sie verbindet die Vorteile und Nachteile der Verwendung von Feature Zweige beschreibt

Es umfasst auch Optionen für die Codezeile owenership und Richtlinien, die Sie implementieren vielleicht gefallen

Answer 3

Eine Sache zu prüfen ist, um tatsächlich Schließen der Feature-Zweig, wenn Sie mit ihm fertig sind, wenn man es zusammengeschlossen hat wieder mit dem Hauptstamm. In diesem Zusammenhang bedeutet die Nähe einfach den Zweig verlassen, nicht eine echte Löschung.

Nach Abschluss der Arbeiten zusammengeführt werden, gibt es wirklich keine Notwendigkeit für den Zweig „existieren“.

Um schnell zu identifizieren, was Zweig Zweig ist, würde ich vorschlagen, eine Namenskonvention Leck „FEAT_MY_FEATURE“ oder „FEAT_20080926“ mit (Startdatum?). Dies würde es einfach, all diese Features Zweige außer Acht zu lassen, wenn die Repository-Struktur durchsuchen.

Answer 4

Ich habe mehrere Jahre in einem Umfeld gearbeitet, in dem dies gängige Praxis war und sehr schmerzhaft war.Stellen Sie sicher, dass die Zusammenführungen Teil Ihres Projektplans sind, da sie viel Zeit in Anspruch nehmen und zu Verzögerungen führen.

Es hat ein wenig geholfen, die Filialen zu dokumentieren und ihnen konkrete Verantwortlichkeiten zuzuweisen.

Wir mussten ein Tool erstellen, das uns dabei hilft, Änderungen inkrementell zusammenzuführen (eine Änderung nach der anderen, anstatt die Spitzen der Zweige zusammenzuführen), da sich CVS nicht gut verhält, wenn die beiden Zweige auseinanderlaufen.

Synchronisieren Sie häufig (mindestens einmal pro Woche).

Ich denke, der beste Weg, dies im Nachhinein anzugehen, wäre, sicherzustellen, dass die Divergenz minimal bleibt und die riskante Entwicklung in verschiedene Meilensteine ​​aufzuteilen, indem man beispielsweise Scrum verwendet.

Ich ermutige Sie auch zum Lesen SCM-Muster.Dieses Buch enthält viele gute Ratschläge.