Имам 7-годишно хранилище. За да направя известна поддръжка, стартирах svnadmin verify в хранилището. Получих грешка за несъответствие на контролната сума при няколко ревизии.
Опитах се да създам дъмп без лошите ревизии и да пресъздам хранилището, но имаше много млади ревизии, които зависят от лошите ревизии. Не мога да архивирам моето хранилище с помощта на svnadmin dump, когато е в това състояние.
Има ли решение за тези грешки, за да се създаде дъмп файл на хранилище?
[Знам, че е свързано в другия отговор на този въпрос, но SO отговорите всъщност не трябва да се свързват с ресурси извън сайта и бих искал да мисля, че този отговор трябва да надживее моя собствен личен блог сайт, така че го публикувам тук за бъдещи поколения .]
Тъй като повторното изграждане на ревизия по ревизия на хранилището винаги е огромна болка, аз направих известно бъркане в червата на хранилището, за да заобиколя проблема.
Симптом:
Изпълнението на svnadmin verify в хранилището води до „несъответствие на контролната сума при четене на представяне“. Резултатът тук е подвеждащ, защото ще каже нещо като „* Проверена версия 23″ на реда преди съобщението за грешка. Това означава, че всъщност ревизия 24 е лоша. Ще откриете също, че ако се опитате да изхвърлите ревизиите от 0 до 23, то успешно ще изхвърли ревизии от 0 до 23, но след това ще се провали на 24. Ако се опитате да изхвърлите ревизии 0:23 и след това 25:HEAD, както направих аз, вероятно ще установете, че ревизията 25:HEAD не работи.
Диагноза:
Една (или повече) от промените във файловете в ревизията, която причинява проблеми, има различна контролна сума от тази, която файлът на ревизията е записал по това време. Така че, когато svnadmin verify преглежда съдържанието на ревизията и преизчислява контролната сума, установява, че те не съвпадат и ви казва. Това означава едно от двете неща: 1) контролната сума, записана по това време, е грешна и данните в ревизията/файла са валидни, или 2) данните в ревизията/файла са повредени и контролната сума в момента е правилна .
Ако файлът, генериращ лошата контролна сума, е текстов файл, може да можете да прегледате съдържанието на ревизионния файл и да проверите дали е забележимо повреден. Ако файлът е двоичен, както беше моят, това вероятно не е опция. Още повече, ако файлът е голям (моят беше няколкостотин MB).
2) изглежда ми по-вероятно, така че има вероятност въпросният файл да е повреден и трябва да поправите данните. Но ако случаят 1) е такъв, тогава всичко, което трябва да направите, е да коригирате контролната сума. Така или иначе вероятно не можете да кажете на този етап – така че най-добре да приемете, че е изчезнал и да работите оттам нататък, или поне да го третирате като подозрителен и да го проверите спрямо други източници на данни, ако е възможно.
Възможно решение:
Ако сте щастливи да приемете, че файлът е повреден, тогава можете да върнете вашето репо обратно към проверима стъпка, като промените контролната сума, записана във файла за ревизия, за да съответства на контролната сума, която ще бъде генерирана от данните, каквито са сега. Данните няма да се променят, така че пак ще трябва да ги потвърдите ръчно или да ги изтриете по-късно, но поне можете да убедите хранилището, че не ви пука.
Процес:
Предполагам, че тук работите директно със сървъра на Linux. Използвам Debian, така че инструменти като grep и hexedit обикновено са налични (въпреки че трябваше да инсталирам hexedit). Същите принципи ще се прилагат за Windows, но инструментите ще трябва да се променят.
1) Идентифицирайте ревизията, която е повредена. Това е просто – това е ревизията след последната успешно потвърдена ревизия
2) Идентифицирайте файла в ревизията, който има лоша контролна сума, и намерете лошата контролна сума в ревизията. Това е по-трудно – ревизионните файлове (съхранени в /repository/db/revs) са двоични, а в моя случай огромни. Но grep е ваш приятел тук. svnadmin verify ви дава контролната сума, която е записана в момента – тя се съхранява във файла за ревизия, точно до описанието на файла. Ето команда grep, която търси в конкретния ревизионен файл за контролната сума, която ни е дадена:
grep -e "79a1686d0dfb8618b8ccfc9eb7d74759" -A 3 -B 3 -b -a main/db/revs/24
Тук дългият низ в кавички е „очакваната“ контролна сума, която svnadmin verify ми даде, следните опции казват да се приеме, че файлът е двоичен (-a) и да се отпечатат 3 реда контекст преди (-B 3) и след (-A 3) всяко съвпадение и най-важното отместването на всеки ред от началото на файл (-b). Това трябва да изведе 7 реда от файла (за щастие разделът, описващ файловете и техните свойства, е предимно текстов)
384989609-id: 5cu.0.r24/384989609
384989633-type: file
384989644-count: 0
384989653:text: 24 75689685 293851064 294285337 79a1686d0dfb8618b8ccfc9eb7d74759
384989724-props: 24 384989543 53 0 113136892f2137aa0116093a524ade0b
384989782-cpath: /path/to/the/bad/file.exe
384989842-copyroot: 0 /
Числото в началото на всеки ред е отместването, скоро ще го използваме. Редът cpath е най-интересен – това е файлът, който можете да очаквате да бъде повреден. Но трябва да променим реда :text:, за да работят нещата. Както е описано тук (потърсете раздела за файловия формат на ревизията), този ред е във формата „ “. Не искаме да променяме първите 4 параметъра – най-вероятно са добре. Но 5-ият параметър е лошата контролна сума и това ще ни трябва в следващата стъпка.
3) Променете лошата контролна сума, за да съответства на „действителната“ контролна сума, която процесът за проверка на svnadmin измисля. Отново, това се отпечатва, когато стартирате проверката. За да направя промяната, използвах hexedit, който за щастие не се опитва да зареди целия (огромен) файл с редакция в паметта. Просто го задействате и натиснете Return, за да въведете отместването във файла, към който да преминете. Той го иска в шестнадесетичен, така че бързо преобразуване превръща 384989653 в 16F279D5. Оттам можете да натиснете Tab, за да превключите към ASCII редактиране, бързо да намерите неправилната контролна сума и да я презапишете с новата, валидна контролна сума; след това натиснете Ctrl-X, за да запишете файла и да излезете.
4) Стартирайте отново svnadmin verify. Сега трябва успешно да провери повредената версия и да продължи напред. Ако не стане, проверете дали ревизията и контролната сума, за които се проваля, са еднакви – ако не са, тогава имате повече повредени файлове/ревизации и трябва да повторите стъпки от 1 до 3, докато всички изчезнат. Надяваме се, че няма да са много. И помнете – само защото вашето хранилище вече може да се провери, не означава, че вашите данни са валидни. Всичко, което сте направили, е да кажете на инструмента svnadmin, че контролната сума за данните, които имате, е същата като контролната сума, която очаква.
Надяваме се, че това ще бъде полезно за други SVN администратори там.
След известно търсене в Google намерих следната публикация.
Следвайки тези насоки, бях в състояние да "поправи" лошите ревизии и да изпълни пълна команда svnadmin verify. Освен това ми позволи да създам пълен дъмп на хранилището.
Недостатъкът на това решение е, че всъщност не поправя лошите ревизии. Просто ги прави чисти, за да може SVN да ги обработва правилно. Предполагам, че ако се опитам да проверя файлове в тези ревизии, може да получа грешки.
Надявам се, че ще помогне на някого.
