Perforce: come integrarsi in più filiali?

Question

Ho la seguente situazione di rami in un repository Perforce: C'è un mainline “tronco” e due rami di rilascio “1.0” e “1.1”. Un ramo "cliente" con modifiche specifiche del cliente è stato separato dalla filiale 1.0. Ora il cliente vuole passare alla versione 1.1. Come posso unire il ramo 1.1 nel ramo cliente? Le modifiche specifiche del cliente dovrebbero rimanere "al top" di 1.1.

Ecco un diagramma per un file interessato:

1.1      -(1)---(2)---(3) 
         /   \  \ 
        /   \  \ 
trunk 100--(101)-(102)--103---104---105---106---107 
      \ 
      \ 
1.0   ---1-----2--... 
       \ 
        \ 
customer   ---1-----2----*3* 

La versione corrente del file sto guardando è la revisione 3 sul ramo cliente.

Se scelgo di integrare il ramo "1.1" con il destinatario "cliente", mi sarei aspettato che l'antenato comune di entrambi sia stato trovato (revisione 100 sulla linea principale) e tutte le revisioni che portano al vertice del ramo 1.1 siano uniti (quelli in parentesi).

Invece Perforce offre solo per unire le revisioni da 1 a 3 del ramo 1.1, che non riesce perché manca le modifiche necessarie che è accaduto sulla linea principale prima.

Come posso convincere Perforce per farlo senza dover guardare ogni file manualmente e selezionando le revisioni per unire? Forse la strategia di ramificazione non è adatta? Cos'altro dovrei fare?

Answer 1

Per effettuare integrazioni facile, vorrei creare una specifica rami trunk_to_custer e 1.1_to_customer e quindi problema:

cd customer-workspace 
p4 integ -b trunk_to_customer @change-number-at-which-1.1-was-branched 
p4 resolve 

forse una via di mezzo presentare qui, e poi

p4 integ -b 1.1_to_customer 
p4 resolve 
p4 submit 

Answer 2

Quando si tenta per integrare la revisione 3 dal ramo 1.1, Perforce ti dirà solo che sta integrando le modifiche su quel particolare ramo, ma la revisione 1 contiene già le revisioni del tronco 101 e 102. Quando si uniscono, Perforce identificherà la revisione del tronco 100 come l'antenato comune per il confl risoluzione ict.

E 'stata la mia esperienza che l'integrazione si sta cercando di fare dovrebbe funzionare. Stai vedendo le modifiche mancanti nella tua fonte integrata (che non può essere spiegata da una risoluzione errata dei conflitti), o stai solo guardando l'output di p4 interchanges?

Answer 3

mi piacerebbe consigliamo vivamente cercando di unire le modifiche del cliente nel bagagliaio. Continuerà a essere un incubo per la manutenzione quando alcuni mesi dopo la linea il cliente vorrà aggiornare a 2.0 + le loro modifiche personalizzate.

Se non si desidera che le modifiche del cliente si riflettano nel progetto principale, prendersi il tempo necessario per ristrutturare il codice in modo da poter esporre il comportamento desiderato del cliente con un flag di compilazione o creare un file di configurazione. Avere entrambe le configurazioni di build in esecuzione nell'elemento della configurazione per garantire che le modifiche future non interrompano la creazione del cliente.