2010-10-12 16 views
5

Mam następującą sytuację oddziałów w repozytorium Perforce: Jest tu mainline "trunk" i dwie gałęzie wydania "1.0" i "1.1". Oddział "klient", ze zmianami specyficznymi dla klienta, został rozgałęziony w gałęzi 1.0. Teraz klient chce przejść do wersji 1.1. Jak mogę połączyć gałąź 1.1 z gałęzią klienta? Zmiany specyficzne dla klienta powinny pozostać "na wierzchu" 1.1.Perforce: jak zintegrować wiele oddziałów?

Oto schemat dla jednego dotkniętego pliku:

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

Aktualna wersja pliku Patrzę na to rewizja 3 na gałęzi klienta.

Jeśli zdecyduję się na integrację oddziału "1.1" z docelowym "klientem", spodziewałbym się, że znaleziono wspólnego przodka obu (wersja 100 w głównej linii), a wszystkie poprawki z tego miejsca prowadzące do końcówki gałęzi 1.1 to: scalone (te w nawiasach).

Zamiast tego tylko Perforce umożliwia scalenie wersji 1 do 3 gałęzi 1.1, co nie powiedzie się, ponieważ brakuje w nim niezbędnych zmian, które miały miejsce w głównej linii.

W jaki sposób przekonać Perforce, aby to zrobiła, bez konieczności ręcznego sprawdzania poszczególnych plików i wybierania wersji do scalenia? Może strategia rozgałęziania jest nieodpowiednia? Co jeszcze powinienem zrobić?

Odpowiedz

0

Aby integracje łatwe, by utworzyć konkretne branże trunk_to_custer i 1.1_to_customer a następnie problem:

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

być może w między złożyć tutaj, a następnie

p4 integ -b 1.1_to_customer 
p4 resolve 
p4 submit 
+0

Jeśli spróbuję "p4 integ -b 1.1_to_customer" otrzymam "nie można zintegrować z ... bez flagi -i" dla każdego pliku, który ma zmiany w gałęzi klienta. Jeśli dodaję "-i", scalanie nie powiedzie się, ponieważ zintegrowane są tylko wersje w gałęzi 1.1, a nie te w trunkingu. – hfs

+0

Perforce nie wie, że zmiany 101 i zmiany 102 są niezbędne dla tego, co wydarzyło się w oddziale 1.1. Dlatego przed integracją 1.1 musisz najpierw zintegrować trunk do 102 klientów. –

+0

Tak, właśnie to zrobiłem na końcu: miałem dwie etykiety na głównej linii, które oznaczały podstawy oddziału 1.0 i 1.1. Najpierw połączyłem "trunk" między tymi etykietami, rozwiązałem wszystko, a następnie scaliłem 1.1 i ponownie rozwiązałem.To się udało. – hfs

2

Podczas próby aby zintegrować wersję 3 z gałęzi 1.1, Perforce powie ci tylko, że integruje zmiany w tej konkretnej gałęzi - ale wersja 1 zawiera już wersje trunkingowe 101 i 102. Podczas scalania Perforce zidentyfikuje wersję trunkingową 100 jako wspólny przodek dla confl. Rezolucja ict.

To było moje doświadczenie, że integracja, którą próbujesz zrobić, powinna działać. Czy widzisz brakujące zmiany w twoim zintegrowanym źródle (które nie mogą być wyjaśnione przez niewłaściwe rozwiązywanie konfliktów), czy tylko patrzysz na wynik p4 interchanges?

2

Sugerowałbym próbę scalenia zmian klienta z bagażnikiem. To będzie koszmar związany z konserwacją, gdy kilka miesięcy później klient chce uaktualnić do wersji 2.0 + swoje niestandardowe zmiany.

Jeśli nie chcesz, aby zmiany klientów zostały odzwierciedlone w głównym projekcie, poświęć czas na restrukturyzację kodu, aby można było ujawnić pożądane zachowanie klienta za pomocą flagi kompilacji lub pliku konfiguracji kompilacji. Miej obie konfiguracje kompilacji działające w CI, aby zapewnić, że przyszłe zmiany nie będą łamać kompilacji klienta.