Determinazione dell'ultimo elenco modifiche sincronizzato in Perforce


117

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.


p4 changes | head -1sembra più facile della maggior parte di queste soluzioni.
Sridhar Sarnobat

Risposte:


91

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

Perché "Funziona solo se non hai inviato nulla dall'area di lavoro in questione"?
gdw2

Se invii una modifica, "p4 changes -s submitted -m1" restituirà il numero dell'elenco delle modifiche. Ad esempio, supponiamo che ti sincronizzi con l'elenco modifiche 5, attendi un paio d'ore e quindi invia l'elenco modifiche 10. Il comando di modifiche sopra riportato restituirà 10.
Rinn

Il collegamento è morto, era questo articolo? answers.perforce.com/articles/KB/3458/
user31389

Nota che puoi usare #haveinvece di @clientname, il che ti evita di dover cercare il nome dell'area di lavoro del tuo client.
yoyo

29

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.


Ricevo: Richiesta troppo grande (oltre 1500000); vedere "p4 help maxresults".
user674669

@ user674669: usa l'opzione -m1 che restituisce solo l'ultimo (1) elenco di modifiche
panako

Questo fornisce le informazioni dell'ultimo elenco modifiche inviato , non dell'ultimo elenco modifiche sincronizzato , che è ciò che l'operazione voleva sapere.
Andreas

@ Marsh Penso che sia in realtà il nome dell'area di lavoro del client, che se non impostato è il nome predefinito del computer. Vedi qui: P4CLIENT .
Andreas Haferburg

15

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

10

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.

9

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


Qual è il nome del cliente? Come posso trovare queste informazioni?
palude

1
Il nome del client @marsh (o anche dello spazio di lavoro) è il nome di un oggetto perforce che contiene la mappatura dal depo del server al file system locale
gsf

2
Upvoting questa risposta, poiché risponde alla domanda effettiva invece di dire "non farlo" (che è un punto valido, ma non risponde alla domanda).
sam hocevar

1
p4 changes -m1 @clientnamecorrere all'infinito ... p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'funziona davvero! Grazie!
simomo

@gsf - grazie, l'ho appena provato sulla mia macchina Linux e ha funzionato!

8

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'

5

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.


Erickson - bel suggerimento, ma penso che copra una serie di circostanze leggermente diverse rispetto alla risposta che ho fornito. Certamente counter funzionerà se è probabile che tu abbia solo la revisione della testina, e il server non è abbastanza occupato in modo che qualcuno, magari lavorando su un altro progetto, non faccia un invio tra la sincronizzazione e la chiamata a p4 counter. Quindi penso che il tuo suggerimento sia probabilmente il migliore quando il sistema di compilazione sta facendo un pull distinto e poi compilato. La mia risposta copre i casi in cui la sincronizzazione può essere separata nel tempo dalla build. Entrambi sono validi a seconda delle circostanze, credo.
Greg Whitfield,

3

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.


2
Notare che questo riporta il numero dell'ultimo elenco di modifiche del depot, COMPRESO gli elenchi di modifiche in sospeso (cioè non ancora inviati). Pertanto, qualsiasi utente che inizi un nuovo lavoro nel proprio client influenzerà questo numero. Questo sarà diverso dall'ultimo elenco modifiche sincronizzato con l'area di lavoro locale.
jasonmray

2

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.


0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.