Перенесення сховища Subversion на стару версію BerkeleyDB. (Cvs subversion BerkeleyDB)
Ключові слова: cvs

, subversion , BerkeleyDB , ( знайти схожі документи )
From: geekkoo < [email protected]. > Newsgroups: email Date: Mon, 14 Sep 2008 17:02:14 +0000 (UTC) Subject: Перенесення сховища Subversion на стару версію BerkeleyDB. Мені треба було перенести репозиторій Subversion з однієї машини на іншу у вигляді тарболла містить його базу даних. При цьому з'ясувалося, що на старій машині subversion був зібраний з BerkeleyDB 4.5, а на новой- 4.4. В результаті просто розпакуванням архівів обмежитися не вдалося, оскільки між BDB різних версій є несумісність в форматі файлів баз даних. Збирати заново Subversion, aprutils, Apache (передбачалося відкрити доступ через https) з новою версією BDB мені не хотілося, натомість я вирішив зробити downgrade репозитария до старішої версії BDB, яка за замовчуванням використовувалася на моєму комп'ютері. На відміну від upgrade, який робиться практично автоматично за допомогою утиліти db_upgrade, виконання відкоту на одну мінорну версію виявилася не цілком очевидною витівкою. Пошук в інтернеті ні до чого не привів, тому довелося діяти на свій страх і ризик. Для цього мені все ж довелося встановити відповідну версію BerkeleyDB (4.5.20), для чого я просто скачав вихідні з сайту Oracle, взяв складальний скрипт зі свого дистрибутива, поміняв там версії пакету і запустив компіляцію. Потім в готовому пакеті перейменував виконувані файли (/ usr / bin / db_ * оскільки тільки їх імена конфліктували з уже наявними з пакета BerkeleyDB4.4), просто додавши до їх імені суфікс 45. Після цього можна було приступати до downgrade. Отже, репозитарій був розпакований в каталог / var / lib / svn, так що його бази даних містяться в підкаталозі / var / lib / svn / db. В першу чергу backup: # cp -a db db.original і можна починати експерименти: # cd db Непогано б почати з відновлення: # db_recover45 -v -e -h ./ і скидання останніх записів в файли даних: # db_checkpoint45 -v - 1 Якщо якісь команди лаються (у мене лаялися, база даних була після креш) і відмовляються працювати, то нічого не поробиш - з надією на краще переходимо до наступного етапу. Я вирішив переносити файли в максимально портабельная форматі, тобто у вигляді dump-а. Однак, для початку варто з'ясувати, dump чого потрібно робити: # db_archive45 -s changes copies lock-tokens locks nodes representations revisions strings transactions uuids ось ці файли і складають базу даних сховища. Ідея полягає в тому, що на початку я скидаю ці файли в проміжне сховище за допомогою db_dump45, а потім завантажую за допомогою db_load, яка вже слінкована з BerkleyDB 4.4.20. Щоб було менше метушні, я написав пару скриптів на tcl: #! / Usr / bin / tclsh exec mkdir ~ / svn.dump set db [exec db_archive45 -s] foreach i $ db {exec db_dump45 -f ~ / svn.dump / $ i.dump $ i} exec cp DB_CONFIG ~ / svn.dump Це щоб скинути архів і конфігураційний файл DB_CONFIG. Запускається скрипт в директорії / var / lib / svn / db, після чого цю директорію можна сміливо видаляти і запускати наступний: #! / Usr / bin / tclsh set h [exec ls ~ / svn.dump] exec mkdir db cd db foreach i $ h {set k [lindex [regexp -inline {(. *) \. dump} $ i] 1] exec cat ~ / svn.dump / $ i | db_load -h ./ $ k} exec cp ~ / svn.dump / DB_CONFIG ./ В результаті маємо каталог db з усіма потрібними файлами всередині. Тепер залишилося увійти в цей каталог і відновити робоче оточення: cd db db_recover -h ./ -e -v В результаті там з'являться ще кілька файлів виду __db. * І log. *. Можна переконатися, що тепер svn працює: svn list file: /// var / lib / svn Я думаю, що ця стратегія - db_checkpoint, db_archive, db_dump, db_load, db_recover, може бути корисна при архівування баз даних інших серверів, що використовують BerkeleyDB, але не мають своїх утиліт архівування. Наприклад, OpenLDAP, де альтернативою може бути тільки скидання і відновлення всього каталогу через ldif формат, що не дуже швидко. Ще один хороший питання - наскільки цей трюк працює при відкат на мажорну версію. Але щось бажання шукати на нього відповідь у мене не виникло.

Обговорення [ RSS ]

• 1.1 , анонім (-), 10:39, 15/09/2008 [ відповісти ]

+

/ - Ух ти, скільки проблем, а чому було відразу не зберігати репозиторій в fsfs? Це більш простий, швидкий, надійний, компактний і взагалі офіційно рекомендований метод.

• 2.2 , geekkoo (??), 11:28, 15/09/2008 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - > Ух ти, скільки проблем, а чому було відразу не зберігати репозиторій в
> Fsfs? Це більш простий, швидкий, надійний, компактний і взагалі офіційно рекомендований
> Метод.

WTF fsfs?

• 3.3 , анонім (-), 15:36, 15/09/2008 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - Тип сховища, можна berkeleyDB, а можна fsfs - файли на диску, по файлу на ревізію. Використовується за замовчуванням помоему з svn 1.3.

bash-3.00 # svnadmin help create
create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
...
--fs-type arg: type of repository: 'fsfs' (default) or 'bdb'
...

• 4.4 , geekkoo (??), 15:58, 15/09/2008 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - > [Оверквотинг видалений]
> Create: usage: svnadmin create REPOS_PATH
>
> Create a new, empty repository at REPOS_PATH.
>
> Valid options:
> ...
> --Fs-type arg
>: Type of repository: 'fsfs' (default) or 'bdb'
>
> ...

Так, дійсно

Коли створювався репозиторій bdb був дефолтних

• 1.5 , Сергіо (?), 23:35, 15/09/2008 [ відповісти ]

+

/ - Можна було зробити простіше:
svnadmin dump REPO_Path> dumpfile.dump
svnadmin load / path / to / new / reponame </path/to/dumpfile.dump

І неважливо які сховища bdb або fsf.

• 2.6 , geekkoo (??), 00:19, 16/09/2008 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - > Можна було зробити простіше:
> Svnadmin dump REPO_Path> dumpfile.dump
> Svnadmin load / path / to / new / reponame </path/to/dumpfile.dump
>
> І неважливо які сховища bdb або fsf.

Я ж з цього і почав - що не хотів збирати заново subversion з новими BerkeleyDB. А той що був не читав новіший формат даних.

• 1.7 , User294 (Ok), 2:47, 16/09/2008 [ відповісти ]

+

/ - Вибачте за різкість але по моєму це називається "відверта онанізм в наслідок некрофілії". У сенсі, спершу штучно придумали собі якихось лівих і дурних проблем а потім з помпою їх разрулілі.От себе хочу зауважити що з досвіду компілежкі беркелеевской БД для не підтримує ними офіційно платформи (!!) воно досить нескладна штука.А заявляти що більш стара версія мовляв не працює з даними від новішою - це і зовсім пі ... ц якийсь то.Даунгрейд взагалі вкрай рідко работает.Мінусом це не є, бо некрофілія - ​​збочення.

• 2.8 , geekkoo (??), 7:14, 16/09/2008 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+

/ - > Вибачте за різкість але по моєму це називається "відверта онанізм в наслідок
> Некрофілії ". У сенсі, спершу штучно придумали собі якихось лівих і дурних
> Проблем а потім з помпою їх разрулілі.От себе хочу зауважити що
> По досвіду компілежкі беркелеевской БД для не підтримує ними офіційно платформи
> (!!) воно досить нескладна штука.

Мова не про компілежке BDB йде, а про Апачі, сабвершене і Apr-утиліти
> А заявляти що старіша версія мовляв
> Не працює з даними від новішою - це і зовсім
> Пі ... ц якийсь то.Даунгрейд взагалі вкрай рідко працює.

Омана. Безпосередньо не працює, через бекапи - працює не завжди, але помітно частіше.

Додати коментар

Спонсори:

Хостинг: