Determinazione dell'ultimo elenco modifiche sincronizzato in Perforce

Una domanda che sorge di tanto in tanto è qual è il modo migliore per determinare l'elenco delle modifiche con cui hai effettuato l'ultima sincronizzazione in Perforce. Questo è spesso necessario per cose come l'inserimento del numero dell'elenco delle modifiche nelle informazioni di revisione dal sistema di compilazione automatico.

Consiglio il contrario per i sistemi di compilazione automatica: dovresti prima ottenere l'ultima lista delle modifiche dal server usando:

p4 changes -s submitted -m1

quindi sincronizza con quella modifica e registrala nelle informazioni di revisione. Il motivo è il seguente. Sebbene Perforce raccomandi quanto segue per determinare l'elenco delle modifiche su cui è sincronizzato lo spazio di lavoro:

p4 changes -m1 @clientname

notano alcuni trucchi:

• Funziona solo se non hai inviato nulla dall'area di lavoro in questione.
• È anche possibile che un'area di lavoro client non sia sincronizzata con alcun elenco modifiche specifico.

e c'è un altro trucco che non menzionano:

• Se l'elenco di modifiche più alto in cui è avvenuta la sincronizzazione ha eliminato rigorosamente i file dall'area di lavoro, verrà riportato l'elenco di modifiche più alto successivo (a meno che anch'esso non sia rigorosamente eliminato).

Se devi prima sincronizzare e registrare in seguito, Perforce consiglia di eseguire il seguente comando per determinare se sei stato morso dai trucchi di cui sopra; dovrebbe indicare che nulla è stato sincronizzato o rimosso:

p4 sync -n @changelist_number

Solo per rispondere io stesso in linea con il suggerimento di Jeff di utilizzare Stackoverflow come luogo in cui conservare frammenti tecnici ...

Dalla riga di comando usa:

p4 changes -m1 @<clientname>

E sostituisci semplicemente con il nome delle specifiche del tuo cliente. Questo produrrà l'output del modulo:

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

Che è facilmente analizzabile per estrarre il numero dell'elenco modifiche.

Puoi provare a trovare il numero massimo di modifiche nell'output del comando "p4 files". Tuttavia, la directory di lavoro non dovrebbe contenere commit post-sincronizzazione. Questo è solo un po 'meglio di

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

poiché quest'ultimo sembra funzionare sul server e potrebbe non funzionare su grandi alberi di sorgenti a causa dei limiti di "MaxResults".

$ 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

dove p4lastchange.py è basato sul codice della presentazione Using P4G.py From the Command Line di JTGoldstone, Kodak Information Network / Ofoto, 15 aprile 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

Se stai usando P4V puoi farlo graficamente:

• Nella scheda Dashboard (Visualizza-> Dashboard) scegli una cartella e vedrai un elenco di elenchi di modifiche con cui la cartella non è ancora aggiornata. Annotare il numero più basso (nella riga più alta).
• Assicurati di aver selezionato nella struttura ad albero dello spazio di lavoro la stessa cartella di prima nel dashboard. Quindi vai alla scheda Cronologia (Visualizza-> Cronologia) e scorri verso il basso fino al numero annotato in precedenza. Il numero appena sotto quel numero è il numero della tua attuale lista delle modifiche.

p4 changes -m1 @clientname che è il modo "consigliato" per farlo per il mio cliente richiede circa 10 minuti

questo è quello che uso:

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

per lo stesso client richiede 2,1 secondi

Puoi anche usare il comando cstat:

p4 help 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'

Per una build seria (quella che viene preparata per il test), specifica esplicitamente l'etichetta o il numero dell'elenco modifiche desiderato, sincronizza con l'etichetta e inseriscilo negli artefatti di build.

Se non viene fornita una lista modifiche (o un'etichetta), utilizzare p4 counter changeper ottenere il numero di modifica corrente e registrarla. Ma devi comunque sincronizzare tutto usando quel numero di modifica.

Non penso che tu possa ottenere esattamente ciò che desideri, perché in generale, un intero spazio di lavoro non è sincronizzato con un particolare numero di lista modifiche. È possibile sincronizzare esplicitamente alcuni file con revisioni precedenti e quindi un singolo numero di elenco modifiche non ha significato. Ecco perché syncè necessario un aggiornamento per garantire che un singolo numero di elenco modifiche rappresenti accuratamente la versione del codice.

Per quanto riguarda i commenti: Sì, la mia risposta è destinata ai gestori di configurazione che preparano una build da consegnare al QA. I nostri sviluppatori normalmente non si sincronizzano come parte di una build; eseguono una build prima dell'invio, in modo che possano assicurarsi che le modifiche non interrompano la build o i test. In quel contesto, non ci preoccupiamo di incorporare un'etichetta di repository.

Con il tuo approccio, stai assumendo che l'intero spazio di lavoro fosse sincronizzato con head al momento dell'ultimo invio dell'elenco delle modifiche e che l'elenco delle modifiche includesse tutti i tuoi file aperti. È troppo facile sbagliare in queste ipotesi, difficili da rilevare e terribilmente costosi in termini di tempo perso. D'altra parte, risolvere il problema è facile, senza inconvenienti. E poiché un numero di lista modifiche può essere specificato in modo esplicito, non importa quale revisione è necessaria o quanto velocemente cambia la base di codice.

Per l'intero deposito (non solo il tuo spazio di lavoro / cliente)

p4 counter change

fa il lavoro, raccontando solo l'ultima lista delle modifiche.

Il meglio che ho trovato finora è eseguire la sincronizzazione con qualsiasi changelist che desideri creare e quindi utilizzare le modifiche -m1 //...#have per ottenere l'attuale elenco di modifiche locale (revisione).

p4 sync @CHANGELIST_NUM p4 changes -m1 //...#have | awk "{print $ 2}"

Ti dà il numero dell'elenco modifiche che puoi usare dove vuoi. Attualmente sto cercando un modo più semplice rispetto alle modifiche di p4 -m1 //...#have.

Non sono sicuro che tu abbia ottenuto la risposta di cui avevi bisogno, ma ho avuto un problema simile. L'obiettivo era scrivere nel nostro logger la versione specifica del progetto. Il problema era che mentre creiamo il nostro makefile, l'intero sistema di compilazione è controllato dalla nostra gestione della configurazione. Ciò significa che tutte le soluzioni che dicono "sincronizza con qualcosa e poi fai qualcosa" non funzionano veramente e non volevo cambiare manualmente la versione ogni volta che eseguiamo il commit (una fonte sicura di errori). La soluzione (che in realtà è suggerita in alcune delle risposte sopra) è questa: nel nostro makefile, eseguo le modifiche p4 -m1 "./...#have" Il risultato per questo è Change change_number on date by user @ client ' msg' Creo semplicemente il messaggio in una stringa che viene stampata dal logger (il numero di modifica è l'elemento importante ma l'altro è utile anche per decidere velocemente se una certa versione contiene modifiche che sai di aver fatto tu stesso senza andare per forza a controllare). Spero che questo ti aiuti.