Determinazione dell'ultimo elenco modifiche sincronizzato in Perforce

Question

Una domanda che sorge occasionalmente è qual è il modo migliore per determinare l'elenco delle modifiche con cui ti sei sincronizzato l'ultima volta in Perforce.Ciò è spesso necessario per cose come l'inserimento del numero dell'elenco delle modifiche nelle informazioni di revisione da parte del sistema di compilazione automatica.

Answer 1

Raccomando il contrario per i sistemi di compilazione automatica:dovresti prima ottenere l'elenco delle modifiche più recenti dal server utilizzando:

p4 changes -s submitted -m1

quindi sincronizza la modifica e registrala nelle informazioni sulla revisione.Il motivo è il seguente.Sebbene Perforce consiglia quanto segue per determinare l'elenco 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 uno spazio di lavoro client non sia sincronizzato con alcun elenco modifiche specifico.

e c'è un ulteriore trucco che non menzionano:

• Se l'elenco modifiche più alto a cui è avvenuta la sincronizzazione ha eliminato definitivamente file dallo spazio di lavoro, verrà segnalato l'elenco modifiche immediatamente successivo (a meno che anch'esso non abbia eliminato file rigorosamente).

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

p4 sync -n @changelist_number

Answer 2

Giusto 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 utilizzare:

p4 changes -m1 @<clientname>

E basta sostituirlo con il nome della specifica client.Ciò produrrà l'output del modulo:

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

Che può essere facilmente analizzato per estrarre il numero della lista delle modifiche.

Answer 3

Potresti 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 alberi di origine di grandi dimensioni a causa dei limiti "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 di Utilizzo di P4G.py dalla riga di comando presentazione di J.T.Goldstone, 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

Answer 4

Potresti anche usare il comando cstat:

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

Answer 5

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 impiega 2,1 secondi

Answer 6

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 stata aggiornata.Prendi nota del numero più basso (nella riga più alta).
• Assicurati di aver selezionato nella struttura dell'area di lavoro la stessa cartella di prima nella 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 lista di modifiche corrente.

Answer 7

Per una build seria (quella in fase di preparazione per il test), specificare esplicitamente l'etichetta desiderata o il numero dell'elenco modifiche, sincronizza con l'etichetta, e incorporarlo negli artefatti di build.

Se non viene fornita una lista di modifiche (o un'etichetta), utilizzare p4 counter change per ottenere il numero di modifica corrente e registrarlo.Ma ne hai ancora bisogno sincronizza tutto utilizzando 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 elenco modifiche.È possibile sincronizzare esplicitamente alcuni file con revisioni precedenti e quindi un singolo numero dell'elenco delle modifiche non ha senso.Ecco perché un fresco sync è necessario per garantire che un singolo numero dell'elenco modifiche rappresenti accuratamente la versione del codice.

---

Per quanto riguarda i commenti:Sì, la mia risposta è destinata all'uso da parte dei gestori della configurazione che preparano una build da fornire 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 apportate non interrompano la build o i test.In questo contesto, non ci preoccupiamo di incorporare un'etichetta di repository.

Con il tuo approccio, stai presupponendo che l'intero spazio di lavoro sia stato sincronizzato con l'intestazione al momento dell'ultimo invio dell'elenco di modifiche e che l'elenco di modifiche includesse tutti i tuoi file aperti.È troppo facile sbagliarsi in queste ipotesi, è difficile da individuare e terribilmente costoso in termini di tempo perso.D'altra parte, risolvere il problema è facile, senza inconvenienti.E poiché è possibile specificare esplicitamente il numero di un elenco di modifiche, non importa quale revisione è necessaria o quanto velocemente cambia la base di codice.

Answer 8

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

p4 counter change

fa il lavoro, semplicemente raccontando l'ultima lista di modifiche.

Answer 9

La cosa migliore che ho trovato finora è eseguire la sincronizzazione con qualsiasi elenco di modifiche che desideri creare e quindi utilizzare modifiche -m1 //...#devi ottenere l'elenco di modifiche locale corrente (revisione).

P4 Sync @Changelist_num P4 Modifiche -M1 //...#Have | awk '{stampa $ 2}'

Ti dà il numero della lista delle modifiche che puoi utilizzare dove vuoi.Attualmente sto cercando un modo più semplice di p4 change -m1 //...#have.

Answer 10

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, il sistema di compilazione complessivo è controllato dalla nostra gestione della configurazione.Ciò significa che tutte le soluzioni che dicono "sincronizza con qualcosa e poi fai qualcosa" non funzionano davvero 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, faccio modifiche P4 -M1 "./...#Have" Il risultato per questo è Cambia Change_number alla data dell'utente@client 'msg' Creo semplicemente il messaggio in una stringa che viene stampata dal logger ( Il numero di modifica è l'elemento importante, ma l'altro è anche utile per decidere rapidamente se una determinata versione contiene modifiche che sai di aver apportato a te stesso senza andare a Perforce per controllare).Spero che questo ti aiuti.