ładowanie subwersji kończy się niepowodzeniem bez „takiej zmiany”

Próbuję nauczyć się migrować repozytorium Subversion i napotykam problem, który nie ma dla mnie sensu. Kiedyś svndumpfilterdzieliłem podprojekt i usunąłem niektóre prefiksy ścieżek. Kilkaset zatwierdzeń importuje się teraz poprawnie, ale pojawia się następujący błąd:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

OK, więc idę do pliku zrzutu patrzeć wersjami 19190 i 19098. Przede wszystkim rewizja 19098 nie istnieje w pliku zrzutu i został przywieziony bez problemu. Wersja 19190 to scalenie. W obrębie 19190 oto informacje o ostatnim pliku, który wydaje się być przyczyną problemu:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Myląco, wersja 19100 NIE istnieje w tym filtrowanym pliku. Ale błąd nie odnosi się do 19100, dotyczy 19098!

Co mam zrobić, aby załadować ten plik?

Dzięki!

Robiłem tego rodzaju podział wielokrotnie. Myślę, że wszystko zależy od tego, jak korzystasz z filtra i jakie przetwarzanie wykonujesz później w pliku zrzutu. Osobiście musiałem również zmienić użytkownika svn obok ścieżki projektu i zmienić numerację wersji. Aby zobaczyć, co można zrobić, tutaj jest istotna część mojego skryptu.

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

To, co się dzieje, polega na tym, że najpierw odfiltrowuję to, czego potrzebuję, usuwam puste wersje z oczywistych powodów i przenumerowuję je. To daje ładne uporządkowane wersje. Następnie upuszczam ścieżkę katalogu głównego projektu, która w moim przypadku była w postaci grupy / klienta, ponieważ w nowym repozytorium, które nie ma sensu (zamiast tego samo repo to grupa / klient na dysku) - są to pierwsze 2 sedy

Następnie usuwam import nienazwanych katalogów, jeden wynikający z powyższych 2 pozycji dla katalogu grupy, a następnie jeden dla dodania katalogu grupy / klienta.

w końcu nakłoniłem autora, aby zmienił go na nowy. Ten również był nieco trudny, ponieważ wymagał zaktualizowania długości definicji właściwości.

Następnie ładuję go i naprawiam uprawnienia systemu plików. Zwróć uwagę na 2 komentarze na temat apache, w niektórych przypadkach będziesz go potrzebować. W końcu dodałem apache do grupy svn.

Teraz nigdy nie miałem fuzji w moich repozytoriach SVN, więc nigdy nie musiałem sobie z nimi radzić podczas podziału. W twoim przypadku wyobrażam sobie, że to, co się dzieje, to źródłowa ścieżka rewizji nie jest importowana i dlatego jej nie znajduje, mimo że błąd narzeka na samą wersję). Zasadą w pliku importu svn jest to, że wszystko, o czym mowa w jednym punkcie, musi zostać zaimportowane przed odwołaniem. Być może odfiltrowałeś coś, czego nie powinieneś, nawet jeśli tego chcesz, lub nie zaktualizowałeś poprawnie pliku zrzutu, aby odzwierciedlić wszelkie inne wprowadzone zmiany.

Jeśli podasz odpowiednią strukturę oryginalnego repozytorium, w tym scaloną ścieżkę źródłową oraz swoje połączenia z parametrami, być może będę w stanie przekazać ci to, co przegapiłeś. Moje pieniądze są u źródła fuzji.

Użyłem doskonałego narzędzia svndumpsanitizer . Problem polega na tym, że struktura repozytorium subversion jest zbyt skomplikowana. Kiedy svndumpfilter jest w wersji 10, nie ma możliwości dowiedzenia się, czy węzeł, który użytkownik chce odrzucić, zostanie przeniesiony do pozycji, którą chce zachować w wersji 113. Więc robi to jedyne, co może zrobić - odrzuca węzeł , aw wersji 113 nie działa, ponieważ już odrzucił dane, które, jak się okazało, byłyby potrzebne.

Svndumpsanitizer działa w inny sposób. Kilkakrotnie skanuje węzły, aby dowiedzieć się, które węzły powinny zostać zachowane. Po ustaleniu, które węzły mają zachować, zapisuje tylko te węzły do ​​pliku wyjściowego. Na koniec - jeśli to konieczne - dodaje zatwierdzenie, które usuwa niechciane węzły, które musiały być przechowywane, aby nie uszkodzić repozytorium.