W przypadku, gdy gałęzie są używane do utrzymywania oddzielnych linii rozwoju, na pewnym etapie będziemy chcieli, aby scalić zmiany dokonane na jednej gałęzi z powrotem do linii głównej lub odwrotnie.
Ważne jest, aby zrozumieć, jak odgałęzienia i scalenia działają w Subversion, zanim zaczniecie ich używać, ponieważ mogą stać się bardzo skomplikowane. Zalecane jest, aby zapoznać się z rozdziałem Rozgałęzianie i scalanie w podręczniku Subversion, który daje pełny opis i liczne przykłady, jak ich używać.
Kolejnym punktem do zaznaczenia jest, że połączenie zawsze ma miejsce w kopii roboczej. Jeśli chcecie scalić zmiany do gałęzi, trzeba mieć pobraną kopię roboczą dla tej gałęzi i wywołać kreatora scaleń z kopii roboczej za pomocą → .
Ogólnie jest to dobry pomysł, aby wykonać połączenie w niezmodyfikowanej kopii roboczej. Jeśli dokonano innych zmian w KR, najpierw je zatwierdźcie. Jeśli scalenie nie wykonało się zgodnie z oczekiwaniami, możecie cofnąć zmiany, a polecenie Wycofaj zmiany usunie wszystkie zmiany, w tym dokonane przed scaleniem.
Istnieją trzy typowe przypadki użycia dla scalenia, które są traktowane w nieco odmienny sposób, co opisano poniżej. Na pierwszej stronie kreatora scalenia jest prośba o wybranie metody, której potrzebujecie.
- Scalenie grupy wersji
Metoda ta dotyczy przypadku, gdy po dokonaniu jednej lub więcej wersji do gałęzi (lub linii głównej) i chcecie przenieść te zmiany w do innej gałęzi.
Wymagacie by Subversion wykonało: „ Obliczenie zmian niezbędnych do uzyskania [OD] wersji 1 gałęzi A [DO] wersji 7 z gałęzi A, i zastosowanie tych zmian do kopii roboczej (linii głównej lub gałęzi B). ”
Jeśli pozostawisz pusty zakres rewizji, Subversion używa funkcjonalności śledzenia zmian aby wyliczyć prawidłowy zakres rewizji. Funkcjonalność jest znana jako reintegracja lub łączenie automatyczne.
- Scalenie dwóch różnych drzew
Jest to bardziej ogólny przypadek metody reintegracji. Prosicie Subversion o wykonanie działań: „ Obliczyć zmiany niezbędne do uzyskania [OD] wersji HEAD linii głównej [DO] wersji head gałęzi i zastosować te zmiany do kopii roboczej (linii głównej). ” W efekcie linia główna wygląda teraz dokładnie jak gałąź.
Jeśli serwer / repozytorium nie obsługuje śledzenia scaleń, to jest jedyny sposób, aby połączyć gałąź z powrotem do linii głównej. Innym przypadkiem wykorzystania występuje wtedy, gdy używacie gałęzi dostawcy i trzeba scalić zmiany wynikające z nowej łaty dostawcy do kodu linii głównej. Aby uzyskać więcej informacji przeczytajcie rozdział o gałęzie dostawców w Podręczniku Subversion.
W polu Z: należy wpisać pełny adres URL folderu gałęzi lub etykiety zawierającego żądane zmiany do dołączenia w kopii roboczej. Możecie też kliknąć by przejrzeć repozytorium i znaleźć odpowiednią gałąź. Jeśli scalaliście już z tej gałęzi, to wtedy po prostu skorzystajcie z listy rozwijanej, która pokazuje historię poprzednio używanych adresów URL.
Jeśli scalacie z gałęzi przemianowanej lub usuniętej, będziecie musieli cofnąć się do wersji, w której gałąź wciąż istniała. W tym przypadku trzeba również wskazać tą wersję jako wersję wieszakową w zakresie wersji do scalenia (patrz poniżej), w przeciwnym wypadku scalenie nie powiedzie się gdy nie będzie w stanie odnaleźć tej ścieżki w HEAD.
W polu Zakres wersji do scalenia wpiszcie listę wersji, które chcecie scalić. To może być jedna wersja, wykaz konkretnych wersji oddzielonych przecinkami lub zakres wersji oddzielonych myślnikiem, lub dowolna ich kombinacja.
Jeśli chcecie, aby wskazać wersję wieszakową dla scalenia, należy dodać wersję wieszakową na końcu wersji, np. 5-7,10@3. W powyższym przykładzie, wersje 5,6,7 i 10 zostaną scalone z 3, która jest wersją wieszakową.
Ważne
Istnieje istotna różnica w sposobie w jaki zakres zmian zostaje określony za pomocą TortoiseSVN w porównaniu z klientem linii poleceń. Najprostszym sposobem wizualizacji jest wyobrazić sobie o ogrodzeniu jako płocie i sztachetach.
Z klientem linii poleceń można określić zmiany na połączenie za pomocą dwóch „płotów” wersji, które określają punkty przed i po.
Z TortoiseSVN należy określić zestaw zmian do scalenia przy użyciu „sztachet”. Powód tego staje się jasny, kiedy podczas korzystania z okna dziennika do określenia wersji do scalenia każda wersja pojawia się jako zestaw zmian.
Gdy scalacie wersje kawałkami, według metody pokazanej w książce Subversion powinniście połączyć wersje 100-200 teraz i 200-300 następnym razem. Zgodnie z TortoiseSVN powinniście scalić 100-200 teraz oraz 201-300 następnym razem.
Różnica ta wniosła dużo ognia na listach dyskusyjnych. Zdajemy sobie sprawę, że istnieje różnica w stosunku do klienta linii poleceń, ale wierzymy, że dla większości użytkowników GUI łatwiejszy jest do zrozumienia sposób, który wdrożyliśmy.
Najprostszym sposobem, aby wybrać potrzebny zakres wersji jest kliknięcie na , ponieważ wypisuje listę ostatnich zmian z ich opisami. Jeśli chcecie scalić zmiany z jednej wersji, zaznaczcie tą wersję. Jeśli chcecie scalić zmiany z kilku wersji, wybierzcie ten zakres (za pomocą zwykłego modyfikatora Shift). Kliknijcie na a wykaz numerów wersji do scalenia zostanie automatycznie wypełniony.
Jeśli chcecie scalić zmiany z powrotem spoza kopii roboczej, aby przywrócić zmiany, które już zostały zatwierdzone, wybierzcie wersje do wycofania i upewnijcie się, że pole wyboru Odwrócone scalanie jest zaznaczone.
Jeśli już scalono pewne zmiany z tej gałęzi, mam nadzieję, że będziecie musieli wpisać notatkę dla ostatniej scalonej wersji w opisie zmiany podczas zatwierdzenia zmiany. W takim przypadku można użyć na kopii roboczej do śledzić ten opis zmiany. Pamiętając, że myślimy o wersji jako zestawie zmian, należy użyć wersji kolejnej po punkcie kończącym ubiegłe scalenie jako punkt startowy dla tego scalenia. Na przykład, jeśli macie już scalone ostatnim razem wersje 37 do 39, to punktem wyjściowym do tego scalania powinna być wersja 40.
Jeśli używacie funkcji śledzenia scaleń Subversion, nie musicie pamiętać, które wersje zostały już połączone - Subversion będzie to notować dla Was. Jeśli pozostawić pusty zakres wersji, wszystkie wersje, które jeszcze nie zostały scalone zostaną uwzględnione. Czytajcie „Śledzenie scalania”, aby dowiedzieć się więcej.
Kiedy używane jest śledzenie scaleń, okno dziennika pokaże uprzednio scalone wersje, i wersje poprzedzające punkt wspólnego przodka, tj. zanim gałąź została skopiowana, jako wyszarzone. Pole wyboru Ukryj niescalalne wersje pozwala na odfiltrowanie tych wersji całkowicie tak aby było widać tylko wersje, które mogą zostać scalone.
Jeśli inni ludzie być może zatwierdzili zmiany, bądźcie ostrożni używając wersji HEAD. Może ona nie odnosić się do wersji o której myślicie, jeśli ktoś zatwierdził po Waszej ostatniej aktualizacji.
Jeśli pozostawisz pusty zakres rewizji lub wybierzesz wszystkie rewizje z pola rozwijanego, Subversion złączy wszystkie jeszcze nie połączone rewizje. Funkcjonalność jest znana jako reintegracja lub łączenie automatyczne.
Istnieją pewne warunki, które stosuje się do scalenia reintegrowanego. Po pierwsze, serwer musi obsługiwać śledzenie scaleń. Kopia robocza musi mieć głębokość nieskończoną (żadnych rzadkich aktualizacji) i nie może mieć żadnych lokalnych modyfikacji, przełączonych elementów ani elementów, które zostały uaktualnione do wersji innej niż HEAD. Wszystkie zmiany linii głównej dokonane w trakcie rozwoju gałęzi muszą być scalone do całej gałęzi (lub oznaczone jako scalone). Zakres wersji do scalenia zostanie obliczony automatycznie.
Wciśnijcie i przejdźcie do „Opcje scalania”.
Jeśli korzystacie z tej metody, aby scalić gałąź funkcji z powrotem do linii głównej, trzeba, aby uruchomić kreatora scalania w kopii roboczej linii głównej.
W polu Z: należy wpisać pełny adres URL folderu z linii głównej. To może źle zabrzmieć, ale pamiętajcie, że linia główna jest punktem początkowym, do którego chcecie dodać zmiany gałęzi. Możecie też kliknąć by przeglądać repozytorium.
W polu Do: należy wpisać pełny adres URL folderu gałęzi funkcji.
W obu polach Od wersji i Do wersji wprowadź numer ostatniej wersji, w której oba drzewa były zsynchronizowane. Jeżeli jesteście pewni, że nikt inny nie robi zatwierdzeń można użyć wersji HEAD, w obu przypadkach. Jeśli jest szansa, że ktoś inny mógł wykonać zatwierdzenie od czasu synchronizacji, skorzystajcie z określonego numeru wersji, aby uniknąć utraty najnowszych zatwierdzeń.
Możecie również użyć do wybrania wersji.
Ta stron kreatora pozwala ustawić opcje zaawansowane, przed rozpoczęciem procesu scalania. W większości przypadków wystarczy używać ustawień domyślnych.
Możecie określić głębokość użytą do scalenia, czyli jak daleko w kopii roboczej powinny się wykonać scalenia. Warunki głębokości są opisane w „Głębokość pobierania”. Głębokość domyślna to Kopia robocza, która używa istniejących ustawień głębokości, i jest to prawie zawsze to, co trzeba.
W większości przypadków chcecie by scalenie uwzględniało historię pliku, więc zmiany w stosunku do wspólnego przodka zostają scalane. Czasami trzeba scalić pliki, które są być może powiązane, ale nie w repozytorium. Na przykład może być zaimportowano wersje 1 i 2 biblioteki strony trzeciej do dwóch odrębnych katalogów. Mimo, że są logicznie powiązane, Subversion nie ma wiedzy o tym, a widzi tylko zaimportowane pliki. Jeśli spróbujecie połączyć różnice pomiędzy tymi dwoma drzewami, to zobaczycie całkowite usunięcie, a następnie pełne dodanie. Aby Subversion używał różnic opartych na ścieżce, a nie różnic opartych na historii, zaznacz pole Ignoruj pochodzenie. Czytajcie więcej na ten temat w podręczniku Subversion, Dostrzeganie lub ignorowanie pochodzenia.
Możecie określić sposób, w jaki zmiany znaku zakończenia linii i białe znaki są obsługiwane. Opcje te zostały opisane w „Opcje końca linii i białych znaków”. Domyślnym zachowaniem jest traktować wszystkie białe znaki i końca linii różnice rzeczywiste zmiany do wykonania scalenia.
Pole wyboru oznaczone Wymuś scalanie służy do uniknięcia konfliktu drzewa, gdzie przychodzące usunięcie wpływa na plik zmodyfikowany lokalnie lub w ogóle nie wersjonowany. Jeżeli plik zostanie usunięty, to nie ma sposobu aby go odzyskać, dlatego ta opcja nie jest zaznaczona domyślnie.
Jeśli używacie śledzenia scaleń i chcecie oznaczyć wersję jako scaloną, bez faktycznego wykonania scalania, zaznaczcie pole wyboru Tylko zapisz fakt scalania. Istnieją dwa możliwe powody zrobienia tego. Możliwe, że scalenie jest zbyt skomplikowane dla algorytmów scalenia, więc wprowadziliście zmiany ręcznie, a następnie zaznaczcie zmiany jako scalone, by algorytm śledzenia scaleń był o tym poinformowany. A może chcecie, aby zapobiec by scalać szczególną wersję. Oznaczenie jej jako już scalonej uniemożliwi scalenia przeprowadzane przez klienty obsługujące śledzenie scaleń.
Teraz wszystko jest ustawione, musicie jedynie kliknąć na przycisk . Jeśli chcecie tylko obejrzeć wyniki, to symuluje operację scalania, ale nie zmienia w ogóle kopii roboczej. Pokazuje tylko listę plików, które będą zmieniane przez prawdziwe scalenie, a zaznacza pliki, gdzie konflikty mogą wystąpić. Ponieważ śledzenie scaleń czyni scalenie znacznie bardziej skomplikowanym, nie można zagwarantować, aby dowiedzieć się wcześniej, czy scalenie zakończy się bez konfliktów, więc pliki oznaczone jako skonfliktowane w teście scalą się w rzeczywistości bez problemu.
Okno dialogowe postępu scalenia pokazuje każdy etap scalania z zakresem zaangażowanych wersji. Może to oznaczać jedną wersję więcej, niż się spodziewaliśmy. Na przykład, jeśli zażądano scalenia wersji 123, okno dialogowe postępu zaraportuje „ Scalenie wersji 122 do 123 ”. Aby to zrozumieć trzeba pamiętać, że Scal jest ściśle związana z Porównaj. Proces scalania działa, generując listę różnic między dwoma punktami w repozytorium i stosując te różnice do kopii roboczej. Dialog postępu po prostu pokazuje początkowy i końcowy punkt różnicy.
Scalanie zostało zakończone. To dobry pomysł, aby przyjrzeć się scaleniu i sprawdzić czy jest ono zgodnie z oczekiwaniami. Scalanie jest zwykle dość skomplikowane. Konflikty pojawiają się często wtedy, gdy gałąź odpłynęła daleko od linii głównej.
Podpowiedź
Gdy wersje są scalane do kopii roboczej, TortoiseSVN generuje komunikat dziennika ze wszystkich scalonych wersji. Są one dostępne przez przycisk w oknie dialogowym zatwierdzenia.
By dostosować ten wygenerowany komunikat, ustaw odpowiednie atrybuty projektu w kopii roboczej. Więcej w „Szablony komunikatów dziennika scaleń”
Dla klientów i serwerów Subversion przed 1.5, żadne informacje o scaleniu nie są przechowywane i scalone wersje muszą być śledzone ręcznie. Po przetestowaniu zmian i dojściu do zatwierdzenia tej zmiany, Wasz opis zmiany do dziennika powinien zawsze zawierać numery wersji, które zostały przeniesione w scaleniu. Jeśli chcecie zastosować inne scalanie w późniejszym czasie trzeba będzie wiedzieć, co już zostało scalone, jeśli nie chcecie nanieść zmiany więcej niż raz. Aby uzyskać więcej informacji na ten temat, patrzcie Najlepsze praktyki scalania w księdze Subversion.
Jeśli serwer i wszystkie klienty używają Subversion 1.5 lub wyższej, Funkcja śledzenia scaleń rejestruje scalone wersje i unika scalania wersji więcej niż raz. To czyni życie znacznie prostszym gdyż można po prostu scalić w pełny zakres wersji za każdym razem, i wiedzieć, że tylko nowe wersje zostaną rzeczywiście scalone.
Zarządzanie gałęziami jest bardzo ważne. Jeśli chcecie utrzymać tą gałąź na bieżąco z linią główną, należy się upewnić, by scalać tak często, by gałąź i linia główna nie odpłynęły zbyt daleko od siebie. Oczywiście, należy wciąż unikać wielokrotnego scalenia zmian, jak wyjaśniono powyżej.
Podpowiedź
Jeśli właśnie scalono gałąź funkcji z powrotem do linii głównej, linia główna zawiera teraz całość nowego kodu funkcji, a gałąź jest już nieaktualna. Możecie ją teraz usunąć z repozytorium jeśli trzeba.
Ważne
Subversion nie może scalić pliku z folderem ani odwrotnie - tylko foldery do folderów i pliki do plików. Jeśli klikniesz na plik i otworzyć okno dialogowe scalania, to trzeba podać ścieżkę do pliku w tym oknie dialogowym. Po wybraniu folderu i pojawieniu się okna dialogowego, należy określić adres URL folderu do scalenia.
Subversion 1.5 wprowadza udogodnienia dla śledzenia scaleń. Podczas scalania zmian z jednego drzewa do drugiego, scalone numery wersji są przechowywane i informacje te mogą być wykorzystywane do różnych celów.
Możesz uniknąć zagrożenia scaleniem tej samej wersji dwa razy (problem powtarzającego się scalenia). Gdy już wersja jest oznaczona jako scalona, przyszłe scalenia, które ją obejmują zakresem, przeskoczą ją.
Podczas scalania gałęzi z powrotem do linii głównej, okno dziennika może pokazać zatwierdzenia gałęzi jako część dziennika linii głównej, dając lepsze możliwości śledzenia zmian.
Po wyświetleniu dialogu dziennika z poziomu okna scalania, wersje już scalone są wyświetlane w kolorze szarym.
Podczas wyświetlania informacji adnotującej plik, możecie wybrać czy pokazać oryginalnego autora scalonych wersji, a nie osobę, która wykonała scalenie.
Możecie zaznaczyć wersje jako nie scalać, umieszczając je na liście wersji scalonych bez rzeczywistego zrobienia scalenia.
Informacje śledzenia scalania są przechowywana w atrybucie svn:mergeinfo przez klienta podczas wykonywania scalania. Gdy scalanie zostało zatwierdzone serwer zapisuje te informacje w bazie danych, a gdy żądacie scalania, opisów zmian lub adnotacji, serwer może odpowiednio reagować. Aby system działał prawidłowo należy upewnić się, że serwer, repozytorium i wszystkie klienty są uaktualniane. Wcześniejszy klient nie będzie przechowywać atrybutu svn:mergeinfo a wcześniejsze serwery nie dostarczą informacji wymaganych przez nowe klienty.
O śledzeniu scaleń w Subversion dowiecie się więcej z Dokumentacji scalenia połaczeń wersji.
Ważne
Teksty w oknach rozwiązywania konfliktów zapewniane sa przez bibliotekę SVN i przez to nie mogły (jeszcze) zostać przetłumaczone jak okna TortoiseSVN. Przepraszamy.
Scalenie nie zawsze przebiega gładko. Czasami występuje konflikt. TortoiseSVN pomaga w tym procesie, pokazując okno dialogowe scalenia konfliktu.
Jest prawdopodobne, że niektóre zmiany zostaną scalone płynnie, podczas gdy inne lokalne modyfikacje wywołają konflikty ze zmianami zatwierdzonymi już do repozytorium. Wszystkie zmiany, które mogą być scalone są scalane. Okno Scalenia Konfliktu daje różne sposoby obsługi linii, które pozostają w konflikcie.
For normal conflicts that happen due to changes in the file content or its properties, the dialog shows buttons which allow you to chose which of the conflicting parts to keep or reject.
- Odłóż
Don't deal with the conflict now. Let the merge continue and resolve the conflicts after the merge is done.
- Accept base
This leaves the file as it was, without neither the changes coming from the merge nor the changes you've made in your working copy.
- Accept incoming
This discards all your local changes and uses the file as it arrives from the merge source.
- Reject incoming
This discards all the changes from the merge source and leaves the file with your local edits.
- Accept incoming for conflicts
This discards your local changes where they conflict with the changes from the merge source. But it leaves all your local changes which don't conflict.
- Reject conflicts
This discards changes from the merge source which conflict with your local changes. But it keeps all changes that don't conflict with your local changes.
- Oznacz jako rozwiązany
Oznacza konflikty jako rozwiązane. Ten przycisk jest wyłączony do czasu użycia przycisku by edytować konflikt ręcznie i zapisać te zmiany do pliku. Gdy zmiany są zapisane, przycsk zostanie włączony.
- Edytuj
Uruchamia edytor scalenia by można było rozwiązać konflikty ręcznie. Nie zapomnijcie zapisać plik by przycisk został włączony.
If there's a tree conflict, please first see „Konflikty drzewa” about the various types of tree conflicts and how and why they can happen.
By rozwiązać konflikt drzewa po scaleniu, wyświetlane jest okno z różnymi opcjami rozwiązania konfliktu:
Ponieważ jest wiele możliwości powstania konfliktu drzewa, w oknie pokazywane są przyciski rozwiązań zależnych od określonego konfliktu. Napisy i etykiety na przyciskach informują jakie opcje rozwiązania konfliktu prezentuje. Jeśli nie jesteście pewni, zamknijcie okno lub skorzystajcie z przycisku by rozwiązać konflikt później.
Podczas opracowywania nowej funkcji przy użyciu odrębnej gałęzi, dobrym pomysłem jest, aby wypracować politykę reintegracji, gdy funkcja jest gotowa. Jeśli inne prace wykonywane są na linii gównej w tym samym czasie, może się okazać, że różnice stają się z czasem znaczące, a scalenie z powrotem staje się koszmarem.
Jeśli funkcja ta jest stosunkowo prosta i rozwój nie potrwa długo, możecie przyjąć proste podejście, polegające na trzymaniu gałęzi w separacji do zakończenia tej funkcji, a następnie scalić zmiany gałęzi z powrotem do linii głównej. W kreatorze scalania będzie to proste działanie Scal zakres wersji, z zakresem wersji jako rozpiętością wersji gałęzi.
Jeśli funkcja będzie dopracowywana dłużej i trzeba brać pod uwagę zmiany w linii głównej, musicie mieć gałąź synchronizowaną. Oznacza to,okresowe scalenia zmian linii głównej do gałęzi, tak, by gałąź zawierała wszystkie zmiany linii głównej oraz z nowej funkcji. Proces synchronizacji wykorzystuje Scal zakres wersji. Gdy funkcja jest zakończona, to możesz połączyć ją z powrotem do linii głównej za pomocą Reintegruj gałąź lub Scal dwa różne drzewa.
Inną (szybką) drogą by scalić wszystkie zmiany z linii głównej do gałęzi funkcji jest użycie → z rozszerzonego menu kontekstowego (należy przytrzymać klawisz Shift podczas prawokliku na pliku).
To okno jest naprawdę proste. Wszystko co trzeba zrobić to ustawienie opcji scalenia, jak to opisano w sekcji „Opcje scalania”. Reszta wykonywana jest przez TortoiseSVN automatycznie przy użyciu śledzenia scaleń.