(Ich bin ein neuer Benutzer, habe aber in der Vergangenheit viele andere Quellcodeverwaltungssysteme verwendet.)
Wir verwenden eine Änderungsliste, um jeden Fehler zu überprüfen. Der Änderungslistenkommentar enthält die Fehler-ID, daher ist es leicht zu verfolgen, wann ein Fehler in einem Ast eingecheckt wurde.
Allerdings kann ich keine einfache Möglichkeit finden, alle Zweige zu finden, die eine enthalten >
Soweit ich feststellen kann, werden nicht alle Zweige verfolgt, in die eine Änderungsliste eingefügt wurde. Wie ich es verstehe, wird die Historie nicht in den Zielzweig kopiert, wenn eine Zusammenführung notgedrungen ist, so dass der einzige Verlauf im Ziel in dem Kommentar der Änderungsliste, in den die Zusammenführung erfolgte, erfolgte.
Was vermisse ich?
Perforce zeigt an, wo Revisionen einer Datei integriert wurden, aber es verbreitet die Eincheckkommentare nicht automatisch mit Ihren Fehlerverfolgungsmetadaten.
Wenn Sie eine Änderungsliste für einen bestimmten Zweig angeben, können Sie feststellen, ob Perforce denkt, dass die Änderungsliste integriert wurde, indem Sie Perforce auffordern, die Änderungsliste zu integrieren. (Ich verwende "Verzweigung" im traditionelleren Quellensteuerungssinn, um einen bestimmten Zweig des Quellcode-Baums zu meinen, anstatt im spezifischen Perforce-Sinn den Pfad der Integration zwischen diesen zwei Quellcode-Bäumen zu bezeichnen.) Lassen Sie uns Angenommen, Sie haben in //source/project/trunk/... gearbeitet und Sie haben eine Änderungsliste @ 1234, die Sie überprüfen möchten, ob sie in Ihren Versionszweig //source/project/rel/... integriert wurde. Erstellen Sie einen Client, der //source/project/rel/... abbildet und führt Folgendes aus:
Wenn Perforce Ihnen mitteilt: "Alle Revisionen sind bereits integriert.", wurde changelist @ 1234 integriert, und dieser Bugfix sollte im Release-Zweig verfügbar sein. Wenn Perforce Dateien auflistet, die geändert wurden, wurden diese Dateien nicht integriert. (Es ist auch möglich, dass einige Dateien in einer Änderungsliste integriert werden und andere nicht, was zu einigen interessanten Problemen führen kann.)
Dies skaliert nicht besonders gut - Sie müssen jeden Bugfix in jedem Zweig überprüfen, den Sie interessieren, obwohl er sich für die Automatisierung eignet.
Sie können den "nicht unterstützten" Perforce-Befehl interchanges verwenden, um eine schnelle Vorstellung davon zu erhalten, welche Änderungslisten nicht von einem Zweig in einen anderen integriert wurden. (Im Perforce-Sprachgebrauch bedeutet "nicht unterstützt" etwas wie "funktioniert vielleicht nicht gleich in der nächsten Version, aber wir denken, dass es nützlich sein könnte, damit wir es trotzdem veröffentlichen"). Um zu sehen, welche Änderungslisten nicht von unserem integriert wurden Beispielstamm zum Freigeben von Verzweigungen ausführen:
In diesem Beispiel habe ich die Änderungsliste @ 1234 nicht aufgelistet, da sie bereits in den Versionszweig integriert wurde. Ein Problem, das ich mit interchanges hatte, ist, dass es nach einer nicht integrierten Änderung jede neuere Version auflistet, auch wenn die neueren Versionen selbst integriert wurden. Wenn Sie Revisionskorrekturen für einen Release-Zweig vornehmen, sehen Sie möglicherweise Änderungslisten wieder aufgeführt. Ich benutze interchanges als ersten Durchlauf, um eine ungefähre Vorstellung davon zu bekommen, was ich integrieren muss. Dann schaue auf integrate , um eine bessere Vorstellung davon zu bekommen, was wirklich fehlt.
(Perforce unterstützt auch ein ähnliches Konzept von "Jobs", das bestimmte Korrekturen an bestimmte Änderungslisten anfügt, aber meine Organisation verwendet sie nicht, so dass ich nicht weiß, wie gut sie funktionieren oder ob sie automatisch weitergeleitet werden Integration.)
Tags und Links perforce