SVN scalania reintegracji brakujących zakresów, ale nic do scalenia

Question

Oto zagadka:

C:\code\trunk> svn merge --reintegrate http://svn.e.com/repos/branches/lih --accept postpone --dry-run 
svn: E195016: Reintegrate can only be used if revisions 11430 through 12384 were previously merged from http://svn.e.com/repos/trunk to the reintegrate source, but this is not the case: 
    branches/lih 
    Missing ranges: /trunk:11902 

Ale jeśli pójdę do katalogu oddziału i spróbować połączyć ten zakres, nie ma nic, aby połączyć!

C:\code\branches\branch> svn merge -r 11901:11902 http://svn.e.com/repos/trunk --accept postpone --dry-run 
C:\code\branches\branch> 

Nawet svn merge -r 11898:11903 nie pokazuje nic do scalenia.

Teraz wydaje się, że nie mogę ponownie zintegrować mojej gałęzi z bagażnikiem! Proszę pomóż!

P.S. Lih branch nie został utworzony przed 11906 r. Był rozgałęziony z gałęzi hd, która była rozgałęziona od pnia (i hd została już z powrotem połączona z tułowiem).

Answer 1

Wydawało się, że działa to dla mnie, ale nie mogę twierdzić, że to rozumiem, ani twierdzić, że jest to najlepszy sposób na rozwiązanie mojego problemu.

Po pierwsze, ważne jest, aby w swoim oddziale były wszystkie najnowsze zatwierdzenia dotyczące trunkingu. Więc zsynchronizuj to (wykonaj scalenie z magistrali do gałęzi).

Następnie można zasadniczo wymusić ponowną integrację, wykonując tę ​​operację w katalogu magistrali: svn merge http://svn.e.com/repos/trunk/@REV http://svn.e.com/repos/branches/lih/ . --dry-run (ale zamień REV na najnowszą wersję #).

Answer 2

Po prostu wpadłem na coś podobnego, gdzie problem polegał na tym, że w bagażniku były dwie anulujące poprawki (tj. Rev 20865 w systemie trunk undid rev 20857). Więc kiedy po raz pierwszy połączyłem się z trunk do branch, nie miałem nic do scalenia dla tej pary wersji, ale nie uwzględniłem ich w mergeinfo dla tych plików. Potem, gdy próbowałem połączyć się z powrotem z odgałęzieniem do pnia, sprzeciwił się brakowi tych dwóch wersji.

Moje rozwiązanie (po ręcznym sprawdzeniu, czy poprawki zostały anulowane w przypadku plików, o których mowa) było jednoznaczne scalenie każdej z dwóch wersji do oddziału (przez svn merge ^/trunk -c 20857 i svn merge ^/trunk -c 20865), zatwierdz, a następnie połącz gałąź z powrotem do pnia. Za drugim razem poszło gładko. Było to z Subversion 1.8.0 (r1490375).

Udało mi się obejść podobny problem wcześniej, wykorzystując scalanie z --record-only, aby oznaczyć zmiany jako poprawnie scalone w oddziale, ale prawdopodobnie bezpieczniej jest scalić rzeczywiste pliki (na wypadek gdyby nastąpiła zmiana nie całkiem anulować).

Wygląda jak błąd w sposobie, w jaki Subversion 1.8 obsługuje mergeinfo do anulowania zmian we mnie.