реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> SVN: совместимость разных версий, апгрейд серверной части и конвертация репозиториев
Doka
сообщение May 8 2007, 18:11
Сообщение #1


Electrical Engineer
******

Группа: СуперМодераторы
Сообщений: 2 163
Регистрация: 4-10-04
Пользователь №: 778



с версии 1.4 в SVN стал использоваться новый формат данных (репозитория?).

есть желание перейти с 1.3.2 на 1.4.3 (интересует большей частью апгрейд сервера)

судя по тому, что при тестировании клиент 1.3.2 смог без ошибок забрать с сервера 1.4.2 рабочую копию репозитория, можно сделать вывод, что изненения коснулись только формата самого репозитария.

значит надо просто(?) переконвертить из 1.3.2 в 1.4 сам репозитарий - трабла в том, что во всем известной книжке я такого раздела не нашел((.

кто-нибудь сталкивался с подобной задачей?

(и вообще - настолько для клиента м.б. прозрачен такой апгрейд сервера?? (предполагаю, что в достаточной мере - но экспериментировать не хотелось бы))
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение May 9 2007, 06:40
Сообщение #2


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Doka @ May 8 2007, 21:11) *
значит надо просто(?) переконвертить из 1.3.2 в 1.4 сам репозитарий - трабла в том, что во всем известной книжке я такого раздела не нашел((.
Плохо искали:
Using your current version of svnadmin,
1) dump your repositories to dump files.

2) Upgrade to the new version of Subversion.

3) Move your old repositories out of the way, and create new empty ones in their place using your new svnadmin.

4) Again using your new svnadmin, load your dump files into their respective, just-created repositories.

5) Be sure to copy any customizations from your old repositories to the new ones, including DB_CONFIG files and hook scripts. You'll want to pay attention to the release notes for the new release of Subversion to see if any changes since your last upgrade affect those hooks or configuration options.

6) If the migration process made your repository accessible at a different URL (e.g. moved to a different computer, or is being accessed via a different schema), then you'll probably want to tell your users to run svn switch --relocate on their existing working copies. See svn switch.


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Doka
сообщение May 9 2007, 12:25
Сообщение #3


Electrical Engineer
******

Группа: СуперМодераторы
Сообщений: 2 163
Регистрация: 4-10-04
Пользователь №: 778



Цитата(Сергей Борщ @ May 9 2007, 10:40) *

хе.. а бегемота-то я и не приметил) спасибо))
репозитории задампил - щас пока временный таймаут - решаю неразрешённые зависимости при установке 1.4.3 (пакеты apr и apr-tool) sad.gif

поэтому уж коль скоро репозитории пересобирать, такой вопрос (над которым раньше не приходилось задумываться): а какой БД (вирт.файловой системой) лучше пользоваться - FSFS или BerkeleyDB ?


--------------------
Блог iDoka.ru
CV linkedin.com/in/iDoka
Sources github.com/iDoka


Never stop thinking...........................
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение May 9 2007, 13:54
Сообщение #4


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Doka @ May 9 2007, 15:25) *
поэтому уж коль скоро репозитории пересобирать, такой вопос (над которым раньше не приходилось задумываться): а какой БД (вирт.файловой системой) лучше пользоваться - FSFS или BerkeleyDB ?
Они там пишут что для новых репозиториев однозначно лучше FSFS хотя бы потому, что не подвержена повреждениям при "падениях".


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
makc
сообщение May 9 2007, 14:42
Сообщение #5


Гуру
******

Группа: Админы
Сообщений: 3 621
Регистрация: 18-10-04
Из: Москва
Пользователь №: 904



Цитата(Сергей Борщ @ May 9 2007, 17:54) *
Они там пишут что для новых репозиториев однозначно лучше FSFS хотя бы потому, что не подвержена повреждениям при "падениях".


Кроме этого у FSFS меньше зоопарк с версиями. Это свойство может оказаться полезным, если один и тот же репозиторий таскается с машины на машину на которых разные версии SVN.


--------------------
BR, Makc
В недуге рождены, вскормлены тленом, подлежим распаду. (с) У.Фолкнер.
Go to the top of the page
 
+Quote Post
spf
сообщение May 10 2007, 03:59
Сообщение #6


Странник
****

Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051



+1 за FSFS
Надежнее из-за простоты реализации, хотя занимает больше места (сейчас не столь актуально) и работает несколько медленнее (сейчас тоже не столь актуально, т.к. производительность современных настольных ПК черезмерна wink.gif)

PS: Subversion Book - неполная дока, некоторые вещи и тонкости есть в "комплектных" документах. В сборке для windows есть .chm файл.


--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
Go to the top of the page
 
+Quote Post
Doka
сообщение May 10 2007, 10:11
Сообщение #7


Electrical Engineer
******

Группа: СуперМодераторы
Сообщений: 2 163
Регистрация: 4-10-04
Пользователь №: 778



спасибо за замечания. таки-обновился!

RPM под конкретную ОСь можно брать тут (не требующий разрешения зависимостей - по зеркалам с оф.сайта почему-то не пошёл - только время с ним потерял).

так же интересная особенность - возможность создания репозитария, совместимого с предыдущими версиями:
Код
$ svnadmin help create
create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
  --config-dir arg         : read user configuration files from directory ARG
  --fs-type arg            : type of repository: 'fsfs' (default) or 'bdb'
  --pre-1.4-compatible     : use format compatible with Subversion versions earlier than 1.4


--------------------
Блог iDoka.ru
CV linkedin.com/in/iDoka
Sources github.com/iDoka


Never stop thinking...........................
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение May 10 2007, 11:02
Сообщение #8


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Doka @ May 10 2007, 13:11) *
так же интересная особенность - возможность создания репозитария, совместимого с предыдущими версиями:
Я не спорю, что в каких-то очень редких случаях (не могу представить в каких) может потребоваться создание репа старой версии. Но делать это для "обычного" репа... Ведь новую версию создавали не зря, в ней убраны какие-то ограничения и недостатки старой, добавлены новые возможности.


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Doka
сообщение May 10 2007, 11:29
Сообщение #9


Electrical Engineer
******

Группа: СуперМодераторы
Сообщений: 2 163
Регистрация: 4-10-04
Пользователь №: 778



Цитата(Сергей Борщ @ May 10 2007, 15:02) *
Я не спорю, что в каких-то очень редких случаях (не могу представить в каких) может потребоваться создание репа старой версии. Но делать это для "обычного" репа... Ведь новую версию создавали не зря, в ней убраны какие-то ограничения и недостатки старой, добавлены новые возможности.

согласен полностью, однако хорошим тоном считается оставлять возможность обратной совместимости со старыми версиями продукта.


--------------------
Блог iDoka.ru
CV linkedin.com/in/iDoka
Sources github.com/iDoka


Never stop thinking...........................
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение May 10 2007, 11:47
Сообщение #10


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(Doka @ May 10 2007, 14:29) *
оставлять возможность обратной совместимости со старыми версиями продукта.
Я не против, честное слово smile.gif. Только под такой совместимостью понял бы возможность работы со старыми репами, а не возможность создания старых репов с которыми собственно работать эта новая версия и не может tongue.gif


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
spf
сообщение May 11 2007, 03:36
Сообщение #11


Странник
****

Группа: Свой
Сообщений: 766
Регистрация: 29-08-05
Из: Екатеринбург
Пользователь №: 8 051



Цитата(Doka @ May 9 2007, 00:11) *
судя по тому, что при тестировании клиент 1.3.2 смог без ошибок забрать с сервера 1.4.2 рабочую копию репозитория, можно сделать вывод, что изненения коснулись только формата самого репозитария.

(и вообще - настолько для клиента м.б. прозрачен такой апгрейд сервера?? (предполагаю, что в достаточной мере - но экспериментировать не хотелось бы))

На самом деле в этом нет ничего удивительного или опасного.
В Subversion заложена модульность, независимость модулей, гибкость(прозрачность) развития и расширения. И то, что работает старый клиент с новым сервером на старом репозитории подтверждает, что у разработчиков это получилось реализовать.
Именно этого нет у CVS, что и стало основным препятствием его развития.


--------------------
"Как много есть на свете вещей, которые мне не нужны!" Сократ
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 7th July 2025 - 02:27
Рейтинг@Mail.ru


Страница сгенерированна за 0.01462 секунд с 7
ELECTRONIX ©2004-2016