Integrazione dei file spostati in perforazione

Supponiamo di aver creato un ramo in modo forzato del nostro codebase. Ecco le specifiche ramo:Integrazione dei file spostati in perforazione

//depot/code/main/... //depot/code/branch/...

Poi, nel ramo, dire che spostare il file a.txt ramificato -> b.txt utilizzando

p4 integrate //depot/code/branch/a.txt //depot/code/branch/b.txt 
p4 delete //depot/code/branch/a.txt

Ora, diciamo che alcuni cambiamenti sono fatti per a.txt in main che vorrei integrare in b.txt nel ramo

Quando provo a integrare utilizzando la specifica di ramo originale, non riflette le modifiche apportate a a.txt in main su b .txt - c'è un modo per fare in modo che le modifiche apportate vengano visualizzate nel file rinominato?

Le specifiche del ramo sono piuttosto grandi (centinaia di modifiche) e alcuni file sono stati rinominati nel ramo, quindi mi piacerebbe avere un modo automatico per farlo. Fammi sapere se posso chiarire qualsiasi cosa qui - sarebbe utile avere una lavagna;)

Grazie! Sam

fonte

2009-12-11 SamBeran

Perforce 2009.1 ha le opportune ridenominazioni, che potrebbero essere d'aiuto in questo modo - probabilmente, e in ogni caso solo per future ridenominazioni. Vedere Perforce 2009.1 release notes, in particolare:

#177023 * ** 
    The new 'p4 move' command allows for better support for 
    renaming files. A file must be already opened for 'edit' 
    or 'add' in order to be moved. Moved files can be synced, 
    resolved and diffed against the repository just like files 
    opened for 'edit'. See 'p4 help move' for more info.

È possibile aggiungere la ridenominazione in spec ramo. Quindi almeno le integrazioni saranno automatiche, anche se le specifiche del ramo saranno ancora più lunghe e complicate.

fonte

2009-12-11 22:50:20

Per quanto ho capito, i benefici * only * del movimento p4 sono che puoi spostare e modificare in modo pulito un file in un singolo elenco atomico, e fino a quando controlla che gli elenchi delle modifiche continuino a propagare le modifiche dalla sorgente alla destinazione. * Dopo * l'hai verificato, si comporta come un ramo, una modifica e un'azione di eliminazione, tranne per il fatto che sono inseparabili. Non aiuta a integrare le mosse da un ramo all'altro. Non è quello che viene chiamato "rinomina di prima classe" in altri sistemi di controllo del codice sorgente. – Weeble

Penso che potresti avere ragione - sembra così - sebbene, con i meta-dati registrati nel database, Perforce potrebbe aggiungere una corretta gestione in futuro? In precedenza era impossibile differenziare il ramo dalla rinomina. –

No, anche con una corretta 'p4 move', l'integrazione non funzionerà come dovrebbe. –

Non ci credo. Dato che non esiste un numero diretto p4 rename, è necessario integrarlo ed eliminarlo: una volta fatto ciò, l'integrazione da un altro ramo non andrà più nel file corretto. Almeno questa è stata la mia esperienza.

fonte

2009-12-11 20:43:34

Grazie - Aggiornato per mostrare quali comandi sono stati effettivamente emessi - in realtà ho usato p4v per farlo. – SamBeran

Credo che il 2009.1 aggiunga i nomi appropriati - che non aiuta la cronologia –

L'unico modo per cui so che Perforce può gestirlo è utilizzare la specifica del ramo per mappare il vecchio file nell'originale nel nuovo file nel ramo. Forse è cambiato con il nuovo comando di spostamento nelle recenti versioni di Perforce, ma non quello che ho vissuto.

fonte

2009-12-12 16:29:57

Ma funziona quando si rinomina ricorsivamente e l'intera directory? Devo fare una specifica di ramo per tutti i file uno per uno? Apparentemente fare una specifica di ramo sulla directory non funziona. – Calmarius

@Calmarius, se si rinomina la directory ei file nella directory, sono necessari entrambi. Se solo la directory fosse cambiata, potresti farlo solo con la directory. Se i nomi cambiano in modo coerente, potresti essere in grado di utilizzare i caratteri jolly per semplificare le specifiche. –

È possibile creare script per la creazione di una specifica di ramo per la gestione di file spostati utilizzando l'output di p4 fstat.

Utilizza il seguente come punto di partenza:

ROOT_PATH="//depot/books/..." 
FIRST_CHANGE=91212 

p4 fstat -Os -T headChange -F "headAction=move/* headChange>$FIRST_CHANGE" $ROOT_PATH|grep headChange | sort -u|while read DUMMY1 DUMMY2 change; do p4 describe $change; done|grep "moved from"|sed 's/\.\.\./\t/g; s/\#[0-9]*//g; s/ moved from//g;'

Questo troverà tutti i file in // depot/libri/... che sono stati spostati nel cambiamento 91212 o poi

Per noi, il uscita di questo assomiglia

//depot/books/bar.txt //depot/books/foo.txt

Usalo per la lavorazione una specifica filiale.

fonte

2011-04-26 14:00:05

È possibile aggiungere l'opzione '-3' per utilizzare un nuovo motore per l'integrazione, che rileverà i file di destinazione precedentemente spostati con 'p4 move' e automaticamente 'retarget' per seguire le operazioni di spostamento .

p4 integrate -3 //depot/code/main/... //depot/code/branch/...

integrerà le modifiche in //depot/code/main/a.txt a //depot/code/branch/b.txt.

Questa è la caratteristica 'UNDOC' in corrente 2010.2 liberatoria, ma sarà il comportamento predefinito nel prossimo 2011.1.

fonte

2011-10-31 09:49:43

+1 Ben avvistato! Questo fa il trucco. –

Integrazione dei file spostati in perforazione

risposta

Problemi correlati