Bestimmen der letzten in Perforce synchronisierten Änderungsliste

Gelegentlich stellt sich die Frage, wie Sie die Änderungsliste, mit der Sie zuletzt in Perforce synchronisiert haben, am besten ermitteln können. Dies wird häufig benötigt, um beispielsweise die Änderungslistennummer vom automatischen Build-System in die Revisionsinformationen einzufügen.

Ich empfehle das Gegenteil für automatische Build-Systeme: Sie sollten zuerst die neueste Änderungsliste vom Server abrufen, indem Sie:

p4 changes -s submitted -m1

Synchronisieren Sie dann mit dieser Änderung und notieren Sie sie in den Revisionsinformationen. Der Grund ist wie folgt. Obwohl Perforce Folgendes empfiehlt , um die Änderungsliste zu bestimmen, mit der der Arbeitsbereich synchronisiert wird:

p4 changes -m1 @clientname

Sie bemerken ein paar Fallstricke:

• Dies funktioniert nur, wenn Sie nichts aus dem betreffenden Arbeitsbereich übermittelt haben.
• Es ist auch möglich, dass ein Client-Arbeitsbereich nicht mit einer bestimmten Änderungsliste synchronisiert wird.

und es gibt ein zusätzliches Gotcha, das sie nicht erwähnen:

• Wenn die höchste Änderungsliste, für die die Synchronisierung durchgeführt wurde, streng gelöschte Dateien aus dem Arbeitsbereich enthält, wird die nächsthöhere Änderungsliste gemeldet (es sei denn, es handelt sich ebenfalls um streng gelöschte Dateien).

Wenn Sie zuerst synchronisieren und später aufzeichnen müssen, empfiehlt Perforce, den folgenden Befehl auszuführen, um festzustellen, ob Sie von den oben genannten Fallstricken gebissen wurden. Es sollte anzeigen, dass nichts synchronisiert oder entfernt wurde:

p4 sync -n @changelist_number

Nur um dies selbst zu beantworten, in Übereinstimmung mit Jeffs Vorschlag, Stackoverflow als Aufbewahrungsort für technische Schnipsel zu verwenden ...

Verwenden Sie in der Befehlszeile:

p4 changes -m1 @<clientname>

Und ersetzen Sie einfach durch den Namen Ihrer Kundenspezifikation. Dies erzeugt eine Ausgabe des Formulars:

Change 12345 on 2008/08/21 by joebloggs@mainline-client '....top line of description...'

Welches leicht analysiert werden kann, um die Änderungslistennummer zu extrahieren.

Sie können versuchen, die maximale Änderungsnummer in der Ausgabe des Befehls "p4 files" zu ermitteln. Das Arbeitsverzeichnis sollte jedoch keine Commits nach der Synchronisierung enthalten. Das ist nur ein bisschen besser als

p4 changes -m1 "./...#have"

Letzteres scheint auf dem Server zu laufen und kann bei großen Quellbäumen aufgrund von "MaxResults" -Limits fehlschlagen.

$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.

$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657

Dabei basiert p4lastchange.py auf dem Code aus der Präsentation von Using P4G.py From the Command Line von JTGoldstone, Kodak Information Network / Ofoto, 15. April 2005.

#! /usr/bin/env python
import sys, os, marshal

if os.name == "nt":
    # Disable newline translation in Windows.  Other operating systems do not
    # translate file contents.
    import msvcrt
    msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )

lastcl = 0
num = 0
try:
    while 1:
        dict = marshal.load(sys.stdin)
        num = num + 1
        for key in dict.keys():
            # print "%s: %s" % (key,dict[key])
            if key == "change":
                cl = int(dict[key])
                if cl > lastcl:
                    lastcl = cl
except EOFError:
    pass
print "Files: %s" % num
print lastcl

p4 changes -m1 @clientname Dies ist die "empfohlene" Methode für meinen Kunden und dauert ungefähr 10 Minuten

das ist was ich benutze:

p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'

für den gleichen Client dauert 2,1 Sekunden

Sie können auch den Befehl cstat verwenden:

p4 hilfe cstat

cstat -- Dump change/sync status for current client

p4 cstat [files...]

Lists changes that are needed, had or partially synced in the current
client. The output is returned in tagged format, similar to the fstat
command.

The fields that cstat displays are:

    change   changelist number
    status   'have', 'need' or 'partial'

Wenn Sie P4V verwenden, können Sie dies grafisch tun:

• Wählen Sie auf der Registerkarte Dashboard (Ansicht-> Dashboard) einen Ordner aus, und Sie sehen eine Liste der Änderungslisten, mit denen der Ordner noch nicht aktualisiert wurde. Notieren Sie die niedrigste Zahl (in der höchsten Zeile).
• Stellen Sie sicher, dass Sie im Arbeitsbereichsbaum denselben Ordner wie zuvor im Dashboard ausgewählt haben. Gehen Sie dann zur Registerkarte Verlauf (Ansicht-> Verlauf) und scrollen Sie zu der zuvor angegebenen Nummer. Die Nummer direkt unter dieser Nummer ist die Nummer Ihrer aktuellen Änderungsliste.

Geben Sie für einen seriösen Build (der zum Testen vorbereitet wird) explizit die gewünschte Beschriftungs- oder Änderungslistennummer an , synchronisieren Sie sie mit dem Etikett und binden Sie sie in Build-Artefakte ein.

Wenn keine p4 counter changeÄnderungsliste (oder Bezeichnung) angegeben ist, verwenden Sie diese , um die aktuelle Änderungsnummer abzurufen und aufzuzeichnen. Sie müssen jedoch immer noch alles mit dieser Änderungsnummer synchronisieren.

Ich glaube nicht, dass Sie genau das erreichen können, was Sie wollen, da im Allgemeinen ein ganzer Arbeitsbereich nicht mit einer bestimmten Änderungslistennummer synchronisiert ist. Man kann einige Dateien explizit mit älteren Revisionen synchronisieren, und dann ist eine einzelne Änderungslistennummer bedeutungslos. Aus diesem Grund ist ein neues syncerforderlich, um sicherzustellen, dass eine einzelne Änderungslistennummer die Codeversion genau wiedergibt.

Zu den Kommentaren: Ja, meine Antwort ist für Konfigurationsmanager gedacht, die einen Build für die Qualitätssicherung vorbereiten. Unsere Entwickler werden normalerweise nicht als Teil eines Builds synchronisiert. Sie führen vor dem Senden einen Build durch, damit sie sicherstellen können, dass ihre Änderungen den Build oder die Tests nicht beschädigen. In diesem Zusammenhang machen wir uns nicht die Mühe, ein Repository-Label einzubetten.

Bei Ihrem Ansatz gehen Sie davon aus, dass Ihr gesamter Arbeitsbereich zum Zeitpunkt Ihrer letzten Übermittlung der Änderungsliste mit head synchronisiert wurde und dass die Änderungsliste alle geöffneten Dateien enthält. Es ist zu leicht, sich in diesen Annahmen zu irren, schwer zu erkennen und in Bezug auf verlorene Zeit schrecklich teuer. Auf der anderen Seite ist die Lösung des Problems einfach und ohne Nachteile. Und da eine Änderungslistennummer explizit angegeben werden kann, spielt es keine Rolle, welche Revision Sie benötigen oder wie schnell sich die Codebasis ändert.

Für das gesamte Depot (nicht nur Ihren Arbeitsbereich / Kunden)

p4 counter change

erledigt den Job und erzählt nur die letzte Änderungsliste.

Das Beste, was ich bisher gefunden habe, ist, die Synchronisierung mit der Änderungsliste durchzuführen, die Sie erstellen möchten, und dann die Änderungen -m1 //...#have zu verwenden, um die aktuelle lokale Änderungsliste (Revision) abzurufen.

p4 sync @CHANGELIST_NUM p4 ändert -m1 //...#have | awk '{print $ 2}'

Gibt Ihnen die Änderungslistennummer, die Sie verwenden können, wo immer Sie möchten. Ich suche derzeit nach einem einfacheren Weg als p4 Änderungen -m1 //...#have.

Ich bin nicht sicher, ob Sie die Antwort bekommen haben, die Sie brauchten, aber ich hatte ein ähnliches Problem. Ziel war es, die spezifische Version des Projekts in unseren Logger zu schreiben. Das Problem war, dass während wir unser eigenes Makefile erstellen, das gesamte Build-System von unserem Konfigurationsmanagement gesteuert wird. Dies bedeutet, dass alle Lösungen, die "Mit etwas synchronisieren, dann etwas tun" sagen, nicht wirklich funktionieren und ich die Version nicht manuell ändern wollte, wenn wir einen Commit durchführen (eine sichere Fehlerquelle). Die Lösung (die in einigen der obigen Antworten tatsächlich angedeutet ist) lautet: In unserem Makefile ändere ich p4 -m1 "./...#have" Das Ergebnis hierfür ist Change change_number am Datum von user @ client ' Nachricht' Ich erstelle die Nachricht einfach in einer Zeichenfolge, die vom Logger gedruckt wird (die Änderungsnummer ist das wichtige Element, aber die andere ist auch nützlich, um schnell zu entscheiden, ob eine bestimmte Version Änderungen enthält, von denen Sie wissen, dass Sie sie selbst vorgenommen haben, ohne sie zu überprüfen). Hoffe das hilft.