[Doka 1]

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

 

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

 

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

 

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

 

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

 

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

[Сергей Борщ 119]

значит надо просто(?) переконвертить из 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 1]

Плохо искали:

хе.. а бегемота-то я и не приметил) спасибо))

репозитории задампил - щас пока временный таймаут - решаю неразрешённые зависимости при установке 1.4.3 (пакеты apr и apr-tool) :(

 

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

[Сергей Борщ 119]

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

Они там пишут что для новых репозиториев однозначно лучше FSFS хотя бы потому, что не подвержена повреждениям при "падениях".

[makc 192]

Они там пишут что для новых репозиториев однозначно лучше FSFS хотя бы потому, что не подвержена повреждениям при "падениях".

 

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

[spf 0]

+1 за FSFS

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

 

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

[Doka 1]

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

 

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

[Сергей Борщ 119]

так же интересная особенность - возможность создания репозитария, совместимого с предыдущими версиями:

Я не спорю, что в каких-то очень редких случаях (не могу представить в каких) может потребоваться создание репа старой версии. Но делать это для "обычного" репа... Ведь новую версию создавали не зря, в ней убраны какие-то ограничения и недостатки старой, добавлены новые возможности.

[Doka 1]

Я не спорю, что в каких-то очень редких случаях (не могу представить в каких) может потребоваться создание репа старой версии. Но делать это для "обычного" репа... Ведь новую версию создавали не зря, в ней убраны какие-то ограничения и недостатки старой, добавлены новые возможности.

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

[Сергей Борщ 119]

оставлять возможность обратной совместимости со старыми версиями продукта.

Я не против, честное слово :). Только под такой совместимостью понял бы возможность работы со старыми репами, а не возможность создания старых репов с которыми собственно работать эта новая версия и не может :tongue:

[spf 0]

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

 

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

На самом деле в этом нет ничего удивительного или опасного.

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

Именно этого нет у CVS, что и стало основным препятствием его развития.