Reintegrate można użyć tylko wtedy, gdy wersje od X do Y zostały wcześniej scalone z <URL> w celu ponownej integracji źródła, ale tak nie jest

127

Używałem gałęzi SVN z Tortoise 1.6. Od czasu do czasu łączę bagażnik z gałęzią, aby był aktualny.

Dzisiaj myślałem, że ponownie zintegruję oddział. Wybrałem „Reintegrate a branch” od Tortoise i otrzymałem następujący komunikat o błędzie:

Reintegrate może być użyte tylko wtedy, gdy wersje od 4709 do 5019 zostały wcześniej scalone ze http://subversion/svn/saxdev/trunkźródłem reintegracji, ale tak nie jest

Następnie wymieniono około 50 plików z opisami takimi jak:

Error: branches/qst/kobalt/sax/businessobjects/util/HistoryParent.java

Error: Missing ranges: /trunk/kobalt/sax/businessobjects/util/HistoryParent.java:4709-5018

Wersja 5019 jest wersją główną. Wersja 4737 była wersją, kiedy tworzyłem gałąź.

Mam to z dziennika wersji 4737

Akcja: Dodano ścieżkę: / branches / qst Kopiuj ze ścieżki: / trunk

Dla mnie ten komunikat o błędzie mówi, że gałąź nie pochodziła pierwotnie z linii głównej, co nie jest prawdą.

Jakieś pomysły?

svn tortoisesvn

— colinjwebb
źródło

1

W porządku. Naprawdę nie używam już Subversion, ale wierzę na słowo!

— colinjwebb

1

Dzięki stary. Myślę, że strona jest do tego lepsza.

— Gray

139

Jeśli pracujesz w gałęzi i na bieżąco aktualizujesz ją z innymi pracami, możesz być zdezorientowany, kiedy tworzysz działającą kopię linii głównej i próbujesz ponownie zintegrować swój oddział, jeśli otrzymasz wiadomość podobną do tej:

$ svn merge --reintegrate https://server.blah/source/orb/branches/bronze_services
svn: Reintegrate can only be used if revisions 650 through 694 were previously merged from
     https://server.blah/source/orb/trunk to the reintegrate source, but this is not the
     case:
  branches/bronze_services/occl
    Missing ranges: /trunk/occl:650-693

Widziałem wiele obejść w Google, ale denerwowały mnie jako „hacki”. Aby rozwiązać ten problem, postanowiłem zrobić to, o czym subversion sugeruje w wiadomości. Wróciłem do mojej gałęzi i wyraźnie scaliłem określone wersje:

$ svn merge -r 650:693 https://server.blah/source/orb/trunk
$ svn commit -m 'merged revisions 650:693 from trunk'
    Sending        occl
Committed revision 695.

Gdy to zrobiłem, mogłem bez problemu wrócić do kopii roboczej pnia i ponownie zintegrować oddział.

mam nadzieję, że to pomoże

— Paul Whipp
źródło

16

Ładny! „róbcie tylko to, co subversion sugeruje w przesłaniu”. :)

— Adam,

7

Zgadzam się, bardziej popularna odpowiedź jest kusząca, ale chyba lepiej to naprawić. Musiałem iść do konkretnego problematycznego pliku i svn mergeto z bagażnika.

— Steve Kehlet

1

To działało świetnie dla mnie. Główna sztuczka polegała na tym, że Tortoise nie powiedział mi o wersji problemu. Po uaktualnieniu mojego klienta svn wiersza poleceń udało mi się go uzyskać, aby przekazać mi wiadomość, taką jak masz, a następnie byłem w stanie scalić wersję problemu i wrócić do linii głównej.

— user12861,

7

To nie zadziałało, ponieważ wymienione "brakujące" scalenia zostały już wykonane w gałęzi (źródło ponownej integracji).

— Sam,

6

Chociaż ta odpowiedź brzmi rozsądnie, to nie zadziałała. Ciągle otrzymywałem te same komunikaty o błędach. Pomogło to usunięcie właściwości svn: mergeinfo z wymienionych plików, tak jak sugeruje zaakceptowana odpowiedź.

— Jenny O'Reilly

85

[[Chociaż moje rozwiązanie działało dla mnie w przeszłości, może prowadzić do niewłaściwych wyników w przypadku nowoczesnych klientów SVN. W naszym przypadku błędy scalania wydawały się być produktami ubocznymi automatyzacji, które myliły naszą historię SVN, a nie rzeczywistą aktywnością. Zostawiam to tutaj dla potomności, ale zamiast tego rozważ zaakceptowaną odpowiedź. ]]

Rozwiązaniem dla mnie było usunięcie wszelkich svn:mergeinfowłaściwości, które w jakiś sposób są dołączane do poszczególnych plików w hierarchii.

svn merge --reintegrate svn+ssh://svn/usr/local/svn/repos/all/trunk 
svn: Reintegrate can only be used if revisions 18765 through 18921 were
    previously merged from svn+ssh://svn/usr/local/svn/repos/all/trunk to the
    reintegrate source, but this is not the case:
trunk/proj/src/main/java/com/foo/furniture.java
Missing ranges: /trunk/proj/src/main/java/com/foo/furniture.java:18765-18920

Aby znaleźć pliki z informacjami o scaleniu, możesz:

cd ~/svn/branches/2.7
svn propget -R svn:mergeinfo .

Następnie możesz usunąć właściwości mergeinfo:

svn propdel svn:mergeinfo proj/src/main/java/com/foo/furniture.java ...
svn commit -m 'removed mergeinfo' proj/src/main/java/com/foo/furniture.java ...

Po ukończeniu tego scalanie przebiegło pomyślnie.

— Szary
źródło

2

To naprawdę pomogło mi rozwiązać mój problem, ale mój był spowodowany scaleniem wersji z folderu podrzędnego, a raczej robieniem tego w folderze głównym. Mój problem polegał na tym, że wykonałem scalanie, ale folder główny nie rozpoznał, że nastąpiło scalenie, co oznaczało, że musiałem ręcznie zaktualizować właściwość mergeinfo o brakujące numery wersji. UWAGA Mogłem to zrobić tylko dlatego, że nie było innych zmian w plikach dla wersji i spowoduje nieoczekiwane zachowanie, jeśli inne pliki będą musiały zostać scalone - w takim przypadku będziesz musiał ponownie scalić wersje.

— ExecutionOrder

5

W TortoiseSVN można kliknąć plik prawym przyciskiem myszy, wybrać „TortoiseSVN” -> „Właściwości” i usunąć właściwość svn: mergeinfo.

— StarCub

3

@StephenKennedy Możesz napotkać problem z ponownym użyciem gałęzi, która została już ponownie zintegrowana. Jeśli tak, zapoznaj się z ostatnią sekcją svnbook.red-bean.com/en/1.7/… zaczynającą się od „Po wykonaniu scalenia --reintegrate z gałęzi do głównej, gałąź nie nadaje się już do dalszej pracy”.

— AlexMA

6

+1. Nie musisz usuwać wszystkich mergeinfos; tylko te, które mają brakujące zakresy. Zobacz moją odpowiedź, aby dowiedzieć się, jak usunąć tylko problematyczne scalenia, filtrując wyjście błędu TortoiseSVN.

— Iain Samuel McLean Elder

4

-1. Nie powinieneś usuwać właściwości mergeinfo, chyba że jesteś naprawdę pewien, co robisz. Wiele osób może to przeczytać, usunąć te właściwości i nieumyślnie wprowadzić inne problemy. Paul Whipp ma lepszą odpowiedź.

— Bizmarck

15

Jeśli spróbujesz ponownie zintegrować swoją gałąź z główną i zobaczysz takie błędy z TortoiseSVN:

Test scalania reintegracji nie powiódł się!: „Ponowna integracja może być użyta tylko wtedy, gdy niektóre wersje zostały wcześniej scalone z linii głównej, ale tak nie jest”

Kliknij tekst błędu i naciśnij CTRL+ A, CTRL+C aby skopiować cały tekst.

Wklej tekst do ciągu tutaj tego skryptu programu PowerShell:

@"
Command: Reintegrate merge http://svn.cloudcorp.com/branches/myproject into C:\Users\iain\Documents\Repositories\CloudCorp\trunk  
Error: Reintegrate can only be used if revisions 18089 through 18612 were previously  
Error:  merged from http://svn.corp.skyscanner.local/svn/SkyScannerDatabase/trunk to  
Error:  the reintegrate source, but this is not the case:  
Error:    
Error:  branches/myproject/userdata/usermanagementservice  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/usermanagementservice:18365,18404  
Error:    
Error:  branches/myproject/userdata/auto_create_db.sql  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/auto_create_db.sql:18406  
Error:   
Error:    
Error:  branches/myproject/userdata/create_audit_tables_triggers_uds.sql  
Error:   
Error:     Missing ranges:  
Error:  /trunk/userdata/create_audit_tables_triggers_uds.sql:18406  
"@ -split "`n" |
? { $_ -match ('Error: +branches') } |
% { $_.Substring($_.IndexOf('userdata')) } |
% { "svn propdel svn:mergeinfo $_" }

Skrypt wyodrębnia względne ścieżki plików z informacją o problemie scalającym i wyświetla listę poleceń, aby naprawić każdy z nich.

Być może będziesz musiał zmienić 'userdata' wartości, aby dopasować ją do struktury repozytorium.

Uruchom skrypt, aby wypisać polecenia potrzebne do usunięcia problemów scalających.

W tym przykładzie skrypt wygeneruje następujące dane wyjściowe:

svn propdel svn:mergeinfo userdata/usermanagementservice  
svn propdel svn:mergeinfo userdata/auto_create_db.sql  
svn propdel svn:mergeinfo userdata/create_audit_tables_triggers_uds.sql

W wierszu polecenia możesz przejść do podstawy oddziału (myproject) i wykonać polecenia, aby usunąć scalone informacje o problemach.

Powinieneś zobaczyć takie wyjście:

property 'svn:mergeinfo' deleted from 'userdata\usermanagementservice'.
property 'svn:mergeinfo' deleted from 'userdata\auto_create_db.sql'.
property 'svn:mergeinfo' deleted from 'userdata\create_audit_tables_triggers_uds.sql'.

Podobnie jak w odpowiedzi Graya , teraz powinieneś zatwierdzić zmiany w gałęzi i spróbować ponownie się zintegrować. Tym razem powinno działać!

— Iain Samuel McLean Elder
źródło

1

Na długo przed ponowną integracją dokonałem scalenia (a nie ponownej integracji) niektórych zmian w linii głównej z mojego oddziału, ponieważ przypadkowo zdecydowałem się na połączenie z moją gałęzią, gdy zamierzałem się do niej zobowiązać. Czy to może być przyczyną tych błędów reintegracji?

— Iain Samuel McLean Elder

Wydaje się, że właśnie to spowodowało ten problem w moim przypadku. Dzięki za poświęcenie czasu na napisanie scenariusza!

— Sam,

@Sam Cieszę się, że okazało się to pomocne. Czy musiałeś zastąpić dosłowne spacje znakiem a, \s+aby działało dla Ciebie?

— Iain Samuel McLean Starszy

Raczej; to było bardziej +potrzebne, żeby to zadziałało dla mnie. W moim przypadku niektóre linie miały dwie spacje, a inne trzy, więc potrzebna była obsługa zmiennej liczby spacji. Nie jestem pewien, dlaczego zmieniłem spację na a \s; to prawdopodobnie nie było potrzebne, przepraszam za tę część!

— Sam

@Sam Nie martw się, ale na razie zmienię to z powrotem na dosłowne miejsce, dopóki TortoiseSVN nie zacznie mieszać go z zakładkami lub czymkolwiek :-) Zostawiłem to, +ponieważ było dla ciebie przydatne.

— Iain Samuel McLean Elder

11

Właściwie naprawiłem to za pomocą opcji „scal dwie różne gałęzie”, aby scalić linię główną i gałąź w moją kopię roboczą. Potem przekazałem to do bagażnika.

Cudowny

— colinjwebb
źródło

4

Ta odpowiedź tak naprawdę nie wyjaśnia, co zrobiłeś. Żadnych przykładów, nawet linku do wymaganej sekcji instrukcji.

— zigg

Z perspektywy czasu nie. Ponieważ jednak była to moja własna odpowiedź tego samego dnia co pytanie, była to najlepsza odpowiedź przez kilka miesięcy. Chciałbym założyć, że ma to sens, jeśli nadal używasz Tortoise SVN 1.6. Zamiast tego zaakceptowałem odpowiedź Graya jako zaakceptowaną odpowiedź.

— colinjwebb

Przykład: svn merge ^ / tags / wx ^ / tags / yz. Wyskoczył mi błąd reintegracji podczas używania 1.8 i łączenia się z bagażnikiem, gdzie źródło scalania miało wcześniej dołączoną do niego konkretną wersję z bagażnika. Wydawało się, że 1.8 zdecydował, że podjęto próbę ponownego scalenia, ale tak nie było. Scalanie na sucho z 1.6 działałoby dobrze, ale dwa scalenia adresów URL też pasują.

— Nick

1

Dokładny scenariusz, który się nie powiódł w wersji 1.8, polegał na skopiowaniu tagu z niektórych wersji z powrotem w celu wydania łatki, wybraniu zmiany z głównej na tylną przez scalenie z łatanym tagiem, dokonaniu dalszej zmiany w załatanym tagu i scaleniu tego z powrotem do bagażnika. Zmiany między tagiem podstawowym a poprawioną wersją są tym, co należy scalić z powrotem do linii głównej, a scalanie adresów URL na 2 adresy URL działa w tym celu.

— Nick

Powinienem był przeczytać tę odpowiedź, zanim spędziłem 3 dni próbując zrozumieć, co się dzieje. Nadal nie rozumiem, dlaczego miałem ten problem, ale podejrzewam, że przyczyną jest komentarz @Nick - a teraz wszystko działa, nie zamierzam dalej szukać ...

— Dave Richardson

6

Coś, co zadziałało dla mnie w SVN z żółwiem: zamiast scalać wszystkie wersje z gałęzi, wybierz określony zakres i ręcznie wybierz wszystkie wersje z gałęzi.

— Olga Perederieieva
źródło

1

Dziękuję za taki podstawowy pomysł. Ze wszystkich odpowiedzi była to nie tylko najmniej skomplikowana, ale jedyna, która mi pomogła.

— redman

3

Po prostu zrób to, co mówi SVN.

Scal gałąź z Reversion, o której mówi SVN
Ponowna integracja z Oddziału do pnia

— Farshid Eilami
źródło

2

Nie działa dla mnie. Zmiany już istniały w branży. Twoje instrukcje wyglądają tak, jakby powinny działać w niektórych przypadkach, ale wydają się być oparte na założeniu, więc nie wydają się uniwersalne.

— Sam,

1

Zobacz także moją odpowiedź tutaj dotyczącą moich doświadczeń z podobnym przypadkiem. Nie jestem pewien, czy to jest źródłem twojego problemu, ale wygląda na to, że Subversion 1.8 ma problemy z informacją o połączeniu, gdy dwie zmiany wzajemnie się anulują.

— dewtell
źródło

0

Natknąłem się na ten problem. Zrobiłem dziennik SVN w moim oddziale, aby dowiedzieć się, czy połączyłem magistralę z moim oddziałem.

Zanotowałem wszystkie poprawki.

Następnie dokonałem scalenia mojej gałęzi z linią główną, określając wersje ręcznie. Podałem wszystkie zakresy, aby wykluczyć wersje, w których scaliłem tułów. Udało mi się połączyć oddział.

Musiałem dokonać kilku zmian w mergeinfo, ale scaliłem kod.

Natychmiast usunąłem swój oddział.

— David
źródło

0

Otrzymałem ten błąd po skorzystaniu z częściowego zamówienia oddziału. Utrzymywałem gałąź na bieżąco z pniem, ale wersje pnia dla części gałęzi, które nie zostały wyewidencjonowane, oczywiście nie były aktualizowane. Rozwiązaniem było pełne pobranie oddziału, a następnie scalenie wszystkich zmian linii głównej. Po przypisaniu ich do gałęzi mogłem pomyślnie scalić gałąź z pniem.

— John W.
źródło

0

Mam ten problem

TortoiseSVN 1.9.7, kompilacja 27907 - 64-bitowa, 2017/08/08 19:34:38
Subversion 1.9.7, -release
kwi 1.5.2
apr-util 1.5.4
poddany 1.3.9
OpenSSL 1.0.2l 25 maja 2017
zlib 1.2.8
SQLite 3.14.1

kliknij prawym przyciskiem myszy gałąź, w której chcesz scalić (ale otrzymujesz ten komunikat) i wybierz opcję "aktualizuj do wersji", a następnie w oknie dialogowym, które zostanie otwarte (zrzut ekranu poniżej) wybierz te wersje i kliknij OK - po scaleniu wszystkich poprzednich wersji, nie dostaniesz tej wiadomości

Dodanie tego tutaj, aby pomóc komuś, kto używa SVN Tortoise

— Akber Iqbal
źródło

-1

Wiem, że to stary post, ale również starałem się rozwiązać ten problem, dopóki nie dowiedziałem się, że pliki wymienione w komunikacie o błędzie mają problem z właściwością SVN.

Kliknąłem prawym przyciskiem myszy problematyczne pliki: TortoiseSVN> Właściwości i stwierdziłem, że plik ma dwa svn: mergeinfo, a jeden z nich nie odziedziczył po danych. Więc usunąłem to mergeinfo.

Używam TortoiseSVN 1.12.2, kompilacja 28653 - 64-bitowa.

— awan.soekamto
źródło