2010-11-03 4 views
13

Versione corta:Perforce: Trova elenco modifiche fonte per un ramo

Dopo ramificazione in P4, come posso scoprire l'elenco modifiche "fonte" del ramo?

Versione lunga:

Diciamo che ho un ramo principale del mio progetto a

//project/main/... 

L'ultimo elenco modifiche presentato qui è @ 123, quando decido di creare un ramo per il rilascio 1.0 in

//project/1.0/... 

Da P4V, viene creato un nuovo elenco delle modifiche (ad esempio @ 130), risolto e inoltrato.

dalla CLI, sarebbe simile a questa:

p4 integrate -c 123 -o //project/main/... //project/1.0/... 
p4 submit 

Più tardi, guardo le changelists sotto //project/1.0, e vedere l'elenco modifiche @ 130 contenente un sacco di file ramificate. Come posso trovare l'elenco delle modifiche no. che questo era originariamente diramato da (ovvero @ 123)?

+0

Nitpick: il comando CLI è 'p4 integra // progetto/principale/... //project/1.0/...'. ('-c 123' fallirebbe perché' -c' specifica un elenco di modifiche * in sospeso * Nell'esempio 123 è già un elenco di modifiche * inviato *) –

+0

@Jon Lavori per Perforce? Succede che ho contattato ieri il loro supporto e hanno fatto notare lo stesso errore che ho fatto :). Il tempismo è stato perfetto. A proposito, suggerisco di usare 'p4 filelog' con fondamentalmente gli stessi parametri che usi per' p4 changes', ma penso che la tua soluzione dia risultati più chiari (cioè posso solo guardare l'elenco delle modifiche di cui ho bisogno, in opposizione al filelog "versione che è molto più prolissa). –

+0

So di aver dato una brutta risposta in origine, ma l'ho completamente rivisto e l'ho fatto in un modo completamente diverso. Volevo solo informarti; Non sono sicuro che gli utenti siano informati delle risposte modificate o meno. – Chance

risposta

8

p4 changes visualizzerà un elenco di changelists inviati, facoltativamente filtrati su un percorso specifico.

p4 changes //project/main/... 
Change 123 ... 'Very last change.' 
Change 122 ... 'Next-to-last change.' 
Change 100 ... 'Only two changes to go...' 
... 

Nessuna sorpresa, ma, come hai trovato, p4 changes è meno utile quando si integrano tutti questi cambiamenti in una singola modifica:

p4 changes //project/1.0/... 
Change 130 ... 'Integrated everything from main.' 

Il trucco è quello di utilizzare l'opzione -i che include tutti gli elenchi di modifiche integrati nei file specificati.

p4 changes -i //project/1.0/... 
Change 130 ... 'Integrated everything from main.' 
Change 123 ... 'Very last change.' 
Change 122 ... 'Next-to-last change.' 
Change 100 ... 'Only two changes to go...' 
... 

per ottenere esattamente quello che volete (123) è necessario scrivere uno script che filtra l'output di p4 changes -i //project/1.0/... di cancellare qualunque cambiamento elencati per p4 changes //project/1.0/... (e poi prendere la modifica più recente rimanente).

(Quando l'esplorazione, ho spesso anche trovare l'opzione -m max utile. Questa limita le modifiche al 'massimo' più recente. Questo aiuta l'output non scorre fuori dallo schermo quando ci sono molti cambiamenti.)

+0

Ma sono sicuro che il cambiamento più recente in 'p4 changes -i' che non è in' p4 changes' sarà il genitore di un determinato changeset? Posso unire il changeset 123 al ramo X, e quindi dopo il merget changeset 20. Quindi, come posso trovare direttamente il genitore di un determinato changeset? –

+0

@AlexanderBird, no Non penso che questa soluzione funzioni quando si uniscono le modifiche avvenute prima delle modifiche che sono già state unite. –

+0

Non molto utile su basi di codice grandi. 'Troppe righe scansionate (oltre 9000000); vedi 'p4 help maxscanrows'. ' – Calmarius

0

Risposta breve:

utilizzare il grafico di revisione in P4V è passo indietro nel tempo e indagare la storia di integrazione. Video on the Perforce website.

Ho utilizzato con successo il grafico di revisione su rami con migliaia di file da tracciare quando una particolare modifica è stata integrata in un ramo. Questo è il motivo per cui l'ho consigliato e collegato a un video di formazione in quanto la maggior parte delle persone lo sottovaluta perché non sa come usarlo.

Risposta lunga:

... [Removed]

UPDATE: Come mostra il grafico di revisione è apparentemente irrealizzabile, si può forse risolvere questo utilizzando un processo/politica, vale a dire, quando si eseguire l'integrazione, aggiungere una nota nella descrizione "Branched @ CL 123". Abbiamo usato questo approccio noi stessi quando ci siamo integrati da un tronco per rilasciare le linee.

+0

Avere un paio di centinaia di file in ciascun ramo rende l'approccio 'Visualizza grafico di revisione' non possibile, purtroppo. Poiché il comando che crea l'integrazione specifica l'elenco delle modifiche sorgente, speravo che le informazioni vengano salvate da qualche parte e non so dove cercare. Immagino che ci sia sempre l'approccio fuzzy di controllare i timestamp degli elenchi di modifiche nel ramo sorgente e trovare quello più vicino al timestamp dell'integrazione. –

+0

Per quanto riguarda l'aggiornamento della risposta: noi * facciamo * utilizzare qualcosa di simile nel nostro processo; Speravo solo che ci fosse un modo automatico, e a nessuno importava cercarlo. –

1

Non conosco alcun comando semplice che esegua ciò che si vorrebbe fare. Se siete disposti a sceneggiatura un po 'e il comando non ha di eseguire velocemente si potrebbe forse tentare di scrittura qualcosa di simile a quanto segue per tutti i file ramificati:

  1. Trova il file di origine/revisione per un file di destinazione.

    p4 filelog //project/1.1/foo.bar#1
    //project/1.1/foo.bar
    ... # 1 cambio 6416 ramo su 2009/07/10 da pippo @bar (text) 'Release 1.1'
    ... ... ramo da // project/main/foo.bar # 1, # 2

  2. Prendi la lista cambiamento a cui è stata presentata il file di origine/revisione.

    p4 fstat //project/main/foo.bar#2
    ... depotFile //project/main/foo.bar
    ... headAction modificare
    ... headType testo
    ... headTime 1.201.771,167 mila
    ... headRev 2
    ... headChange
    ... headModTime 1201770971

  3. Ripetere l'operazione per tutti i file nel ramo e selezionare il numero massimo di modifiche (headChange sopra), che dovrebbe essere l'ultima modifica inviata al genitore prima della diramazione per quel file specifico. Puoi ottenere un elenco completo di tutti i file ramificati utilizzando, ad es. "file p4 //project/1.0/...#1".

(o forse prendere la via più facile e chiedere supporto Perforce)

0

Risposta Aggiornamento: Penso che questo funzionerà. Prova questo:

p4 interchanges from_branch to_branch 

Questo mostrerà le modifiche non integrate dal ramo principale al ramo di rilascio. Credo che puoi utilizzare il numero dell'elenco delle modifiche in alto meno 1 per trovare l'elenco delle modifiche sorgente. interchanges è una funzionalità CLI Perforce non documentata. Per ulteriori informazioni, digitare p4 help interchanges per ulteriori informazioni su questo comando.

Anche in questo caso, I penso che il funzionerà. Potrebbero esserci alcuni casi speciali in cui non lo faranno, ma è la mia ipotesi migliore per un problema difficile e importante.

+1

Nitpicking un po ': se il ramo è stato eseguito quando la modifica 120 è stata l'ultima modifica inviata a // project/main e la modifica dell'integrazione inviata è stata numerata 129, main @ 120 e [email protected] dovrebbero essere identici per la maggior parte degli scopi pratici, ma ricorda che puoi modificare il target prima di inviare "promuovendo" il target da aggiungere usando "p4 edit" e poi modifica il contenuto del file. – rjnilsson

+0

Dopo l'integrazione, potrei aver bisogno di selezionare gli elenchi di modifiche per il back-porting da main a 1.0.Voglio l'integrazione iniziale CL da/main (@ 123 nel mio esempio) per vedere esattamente cosa è stato aggiunto al main dopo il punto di integrazione. (È plausibile che ci possano essere cambiamenti in/main tra @ 123 e @ 130) –

+0

L'ho appena ricevuto. Si sta ramificando da un precedente elenco di modifiche, non (necessariamente) il più recente. – Chance

0

Se si utilizza la scheda storia P4V che vi mostrerà tutti i changelists presentate contro un ramo, in modo da guardare a questo per

//project/1.0/... 

una volta trovata l'elenco modifiche più antica presentata, poi su uno qualsiasi dei file in quell'elenco delle modifiche è possibile visualizzare il grafico delle revisioni per questo, questo ti mostrerà il ramo dal quale è stato integrato il file (e il resto dei file).

Vedrò se riesco a tornare con i comandi p4 per fare la stessa cosa.

1

Poiché nessuno delle risposte finora forniscono il codice per trovare l'elenco delle fonti o l'elenco delle modifiche di un ramo, ho pensato di fornire un one-liner per farlo. Questo approccio si basa sul suggerimento di @ Cwan e stamperà l'elenco di modifiche "principale" da cui è stato creato il ramo. L'argomento FIRST_BRANCH_CL deve essere sostituito con l'elenco delle modifiche della creazione del ramo (vale a dire il primo elenco delle modifiche presentato al nuovo ramo). Come esempio concreto, sostituendo FIRST_BRANCH_CL con 130 dalla domanda originale, questa uscita singola emetterebbe 123.

p4 describe -s FIRST_BRANCH_CL | perl -lne 'if(/^\.\.\. (.+#[0-9]+) .+$/) {print quotemeta $1}' | xargs p4 filelog -m1 | perl -lne 'if(/^\.\.\. \.\.\. branch from (.+#[0-9]+)/) {print quotemeta $1}' | xargs p4 fstat | perl -lne 'if(/^\.\.\. headChange (\d+)/) {$MaxCL=$1 if($1 > $MaxCL)} END {print $MaxCL}' 
+0

Ehi, questo in realtà sembra funzionare! L'ho provato su una delle nostre filiali, dopo aver trovato le stesse informazioni utilizzando i passaggi manuali delineati da Jon-Eric. Ci vuole un po 'per correre, però. – fencekicker

+0

Bello, ma penso che sarebbe bello se spiegassi la logica alla base del tuo rivestimento. – Kostas

0

"p4 integrated" ha funzionato per me. Cerca "copia da" nella descrizione