Dlaczego połączenie 3-way jest korzystne w stosunku do połączenia 2-way?
Wikipedia mówi, że 3-way merge jest mniej podatne na błędy niż 2-way merge i często times nie wymaga interwencji użytkownika. Dlaczego tak jest?
Pomocny byłby przykład, w którym 3-way merge powiodło się, a 2-way merge nie powiodło się.
4 answers
Powiedzmy, że ty i twój przyjaciel sprawdziliście plik i wprowadziliście w nim pewne zmiany. Usunąłeś linię na początku, a Twój znajomy dodał linię na końcu. Następnie zatwierdził swój plik, a ty musisz połączyć jego zmiany z Twoją kopią.
Jeśli wykonujesz dwukierunkowe scalanie (innymi słowy, różnicowanie), narzędzie może porównać dwa pliki i zobaczyć, że pierwsza i ostatnia linia są różne. Ale skąd miałby wiedzieć, co zrobić z różnicami? Czy wersja scalona powinna zawierać pierwsza linia? Powinna zawierać ostatnią linijkę?
Przy trójdrożnym scalaniu, może porównać dwa pliki, ale może również porównać każdy z nich z oryginalną kopią (zanim któryś z Was go zmienił). Aby zobaczyć, że usunąłeś pierwszą linię, a Twój znajomy dodał ostatnią linię. I może wykorzystać te informacje do wytworzenia połączonej wersji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-02-01 17:19:48
Ten slajd z prezentacji perforce jest interesujący:
Podstawowa logika trójdrożnego narzędzia scalającego jest prosta:
- Porównaj pliki bazowe, źródłowe i docelowe
- Zidentyfikuj "kawałki" w pliku plików źródłowych i docelowych:
- kawałki, które nie pasują do bazy
- kawałki, które pasują do bazy
- następnie połącz wynik składający się z:
- The kawałki, które pasują do siebie we wszystkich 3 plikach
- kawałki, które nie pasują do bazy w źródle lub w celu, ale nie w obu
- kawałki, które nie pasują do bazy, ale pasują do siebie (tzn. zostały zmienione w ten sam sposób zarówno w źródle, jak i w celu)
- symbole zastępcze dla fragmentów, które są w konflikcie, do rozwiązania przez użytkownika.
Zauważ, że "kawałki" na tej ilustracji są czysto symboliczne. Każdy może reprezentować linie w pliku lub węzły w hierarchii, a nawet pliki w katalogu. Wszystko zależy od tego, do czego jest zdolne konkretne narzędzie scalające.
Możesz pytać, jaką przewagę daje połączenie 3-drożne nad połączeniem 2-drożnym. W rzeczywistości nie ma czegoś takiego jak dwukierunkowe scalanie, tylko narzędzia, które rozróżniają dwa pliki i pozwalają "scalić", wybierając kawałki z jednego lub drugiego pliku.
tylko 3-way merge daje możliwość sprawdzenia, czy fragment jest zmianą od pochodzenie i czy zmienia konflikt.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-09-22 10:21:01
Napisałem bardzo szczegółowy post na ten temat. Zasadniczo nie można śledzić usuwania/dodawania za pomocą dwukierunkowego, bardzo, bardzo nieproduktywnego.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-01-04 19:32:47
Połączenie trójdrożne, w którym dwa zestawy zmian do jednego pliku bazowego są scalane podczas ich stosowania, w przeciwieństwie do stosowania jednego, a następnie scalania wyniku z drugim.
Na przykład, posiadanie dwóch zmian, w których wiersz jest dodawany w tym samym miejscu, może być interpretowane jako dwa uzupełnienia, a nie zmiana jednego wiersza.
Na przykład
Plik a został zmodyfikowany przez dwie osoby, jedną dodającą łosia, drugą myszkę.
#File a
dog
cat
#diff b, a
dog
+++ mouse
cat
#diff c, a
dog
+++ moose
cat
Teraz, jeśli połączymy zestawy zmian w czasie ich stosowania, będziemy get (3-way merge)
#diff b and c, a
dog
+++ mouse
+++ moose
cat
Ale jeśli zastosujemy b, to przyjrzyjmy się zmianie Z b na c, będzie to wyglądało tak, jakbyśmy zmieniali " u " NA " o " (2-way merge)
#diff b, c
dog
--- mouse
+++ moose
cat
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-02-03 12:22:29