Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SVN: совместимость разных версий
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Управление проектами
Doka
с версии 1.4 в SVN стал использоваться новый формат данных (репозитория?).

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

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

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

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

(и вообще - настолько для клиента м.б. прозрачен такой апгрейд сервера?? (предполагаю, что в достаточной мере - но экспериментировать не хотелось бы))
Сергей Борщ
Цитата(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.
Doka
Цитата(Сергей Борщ @ May 9 2007, 10:40) *

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

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


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

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

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

согласен полностью, однако хорошим тоном считается оставлять возможность обратной совместимости со старыми версиями продукта.
Сергей Борщ
Цитата(Doka @ May 10 2007, 14:29) *
оставлять возможность обратной совместимости со старыми версиями продукта.
Я не против, честное слово smile.gif. Только под такой совместимостью понял бы возможность работы со старыми репами, а не возможность создания старых репов с которыми собственно работать эта новая версия и не может tongue.gif
spf
Цитата(Doka @ May 9 2007, 00:11) *
судя по тому, что при тестировании клиент 1.3.2 смог без ошибок забрать с сервера 1.4.2 рабочую копию репозитория, можно сделать вывод, что изненения коснулись только формата самого репозитария.

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

На самом деле в этом нет ничего удивительного или опасного.
В Subversion заложена модульность, независимость модулей, гибкость(прозрачность) развития и расширения. И то, что работает старый клиент с новым сервером на старом репозитории подтверждает, что у разработчиков это получилось реализовать.
Именно этого нет у CVS, что и стало основным препятствием его развития.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.