SVN, jak rozwiązywać nowe konflikty drzew, gdy plik jest dodawany do dwóch gałęzi

Podczas łączenia kilku gałęzi (przy użyciu SVN 1.6.1), w których plik został dodany do obu gałęzi (a następnie pracowałem w tych oddzielnych gałęziach), otrzymuję jeden z nowych konfliktów drzew:

      C foo.txt
  >   local obstruction, incoming add upon merge

Potrzebuję zmian z obu gałęzi, ale konflikt drzewa nie daje mi zwykłych plików .working, .merge-left i .merge-right - co jest zrozumiałe ze względu na naturę konfliktu. Istnieje kilka takich konfliktów i takie, w których nastąpiło usunięcie tego samego pliku w każdej gałęzi, ale są one łatwe do rozwiązania.

Jak mogę rozwiązać ten problem? Książka SVN Redbean (dla wersji 1.6) nie obejmuje tej sytuacji.

Jak wspomniano w starszej wersji (2009) dokumentu projektowego „Tree Conflict” :

Konflikt XFAIL ze scalania pliku z dodatkowymi wersjami

Ten test wykonuje scalanie, które dodaje plik bez historii do istniejącego wersjonowanego pliku .
Powinien to być konflikt drzewa w pliku local obstruction, incoming add upon mergeodmiany „ ”. Naprawiono oczekiwania w r35341.

(Nawiasem mówiąc, jest to również nazywane „złymi bliźniakami” w ClearCase):
plik jest tworzony dwukrotnie (tutaj „dodawany” dwa razy) w dwóch różnych gałęziach, tworząc dwie różne historie dla dwóch różnych elementów, ale o tej samej nazwie.

Teoretycznym rozwiązaniem jest ręczne scalenie tych plików (za pomocą zewnętrznego narzędzia porównywania) w gałęzi docelowej ' B2'.

Jeśli nadal pracujesz nad gałęzią źródłową, idealnym scenariuszem byłoby usunięcie tego pliku z gałęzi źródłowej B1, scalenie z powrotem z B2do B1, aby ten plik był widoczny B1(wtedy będziesz pracować nad tym samym elementem).
Jeśli scalanie z powrotem nie jest możliwe, ponieważ scalanie odbywa się tylko od B1do B2, wówczas ręczne scalanie będzie konieczne dla każdego scalenia B1->B2.

Znalazłem post sugerujący rozwiązanie tego problemu . Zaraz będzie działać:

svn resolve --accept working <YourPath>

który zażąda plików wersji lokalnych jako OK.
Możesz go uruchomić dla pojedynczego pliku lub całych katalogów projektów.

A jeśli nadchodzące zmiany są tymi, których chcesz? Nie mogę uruchomić rozwiązywania svn - zaakceptuj ich pełne

svn solution - zaakceptuj bazę

Po prostu udało mi się dość dokładnie zaklinować, próbując podążać za radą user619330 powyżej. Sytuacja była taka: (1): podczas pracy nad moją początkową gałęzią, gałąź1, dodałem kilka plików; (2) Stworzyłem nową gałąź, gałąź 2 do dalszego rozwoju, odgałęzienie jej od pnia, a następnie połączenie moich zmian z gałęzi1 (3) Współpracownik skopiował moje mody z gałęzi 1 do swojej własnej gałęzi, dodał kolejne mody, a następnie połączono z powrotem w pniu; (4) Chciałem teraz scalić najnowsze zmiany z linii głównej do mojej bieżącej gałęzi roboczej, branch2. To dotyczy svn 1.6.17.

Scalanie powodowało konflikty drzew z nowymi plikami i chciałem nową wersję z linii głównej, w której się różnią, więc z czystej kopii branch2, usunąłem svn pliki będące w konflikcie, zatwierdziłem te zmiany branch2 (tworząc w ten sposób tymczasowy wersja branch2 bez plików, o których mowa), a następnie wykonałem połączenie z pnia. Zrobiłem to, ponieważ chciałem, aby historia pasowała do wersji głównej, aby później nie mieć więcej problemów, gdy próbuję ponownie połączyć się z magistralą. Scalanie poszło dobrze, mam wersję trunkingową plików, svn st pokazuje wszystko w porządku, a następnie trafiłem na więcej konfliktów drzew podczas próby zatwierdzenia zmian, między usunięciem, które zrobiłem wcześniej, a dodaniem z scalania. Czy svn rozwiązał konflikty na korzyść mojej kopii roboczej (która teraz miała wersję trunkingową plików) i dostałem ją do zatwierdzenia.

Więc nie. Aktualizacja kolejnej kopii branch2 zaowocowała starą wersją plików (scalenie przed magistralą). Więc teraz mam dwie różne kopie robocze branch2, rzekomo zaktualizowane do tej samej wersji, z dwiema różnymi wersjami plików i obie nalegają, że są w pełni aktualne! Wyewidencjonowanie czystej kopii branch2 spowodowało powstanie starej (sprzed linii trunk) wersji plików. Aktualizuję je ręcznie do wersji trunk i zatwierdzam zmiany, wracam do mojej pierwszej kopii roboczej (z której pierwotnie przesłałem zmiany linii głównej), próbuję ją zaktualizować i teraz otrzymuję błąd sumy kontrolnej w tych plikach. Zdmuchnij katalog, o którym mowa, zdobądź nową wersję przez aktualizację i na koniec mam dobrą wersję branch2 ze zmianami linii głównej. Mam nadzieję. Caveat developer.