FSFS Логическая адресация: нет

Question

Я пытаюсь обновить сервер Subversion с 1.6 до 1.9, я установил модули mod_dav и двоичные файлы svn. Большая особенность svn 1.9 - это файловая система FSFS формата 7, которая имеет хорошее количество функций, чтобы включить все эти функции, я просто запускаю команда обновления svnadmin, которая дает мне следующий вывод

Path: repo1<br>
UUID: c67fd7ed-3808-3f41-9d25-6d8197ee6fd9<br>
Repository Format: 5<br>
Compatible With Version: 1.9.0<br>
Repository Capability: mergeinfo<br>
Filesystem Type: fsfs<br>
Filesystem Format: 7<br>
FSFS Sharded: yes<br>
FSFS Shard Size: 1000<br>
FSFS Shards Packed: 0/320<br>
FSFS Logical Addressing: no<br>
Configuration File: repo1/db/fsfs.conf<br>

Здесь, в соответствии с примечаниями к выпуску, чтобы включить все функции формата 7, FSFS Logical Addressing: Да (ранее это было нет), поэтому мой вопрос заключается в том, как установить для свойства выше значение Да

Answer 1

Вы можете изменить тип адресации контента в repo1/db/fsfs.conf файл. Но тебе действительно нужно? Скорее всего, нет.:)

Существует два типа адресации ревизионного содержимого в репозиториях Subversion: физическая адресация и логическая адресация.

• Физическая адресация является наиболее надежным и надежным подходом для обращения к содержимому ревизий в репозиториях Subversion.

• Логическая адресация является необязательным подходом для обращения к содержимому ревизии в репозиториях. Логическая адресация была введена в формате FSFS версии 7 (новое в Subversion 1.9). Логическая адресация добавляет дополнительный слой перевода для функций, которые будут реализованы в будущих версиях Subversion.

Answer 2

Вы можете сделать это молча, но я надеюсь, что у вас достаточно дискового пространства для конвертации. просто вы можете создать новый репозиторий, а затем применить новую конфигурацию. это может быть сохранено рядом с оригинальным хранилищем. затем вы настраиваете зеркалирование из исходного в новое хранилище, затем вызываете двоичный файл svnmirror. рекомендуется сделать компрессию. это может замедлить работу, но в моей практике это невидимо для пользователей. тогда вы можете сжать репозиторий, тогда резервное копирование будет намного проще, с помощью пакета svnadmin. После этого вы можете самостоятельно протестировать новый репозиторий и...... на очень короткое время выключить репозиторий, заменить его новым и включить. Помните, что при переключении вы должны скопировать UID репо со старого на новый. сделать это вместе с копированием крючков. Если все в порядке, вы можете перенести старый репо в другое место и, наконец, уничтожить. Вы можете сделать это со всеми репозиториями шаг за шагом, с очень короткой недоступностью.

кое-что о логической адресации. Я думаю, так же, как bahrep, логическая адресация очень свежа. Это будет лучше, это будет проверено кем-то другим, а не нами:)

Я определил некоторые параметры в своих репозиториях в fsfs, например, общий доступ к репо как true (уменьшение дубликатов), разделение каталогов (то же самое) вместе с реквизитом и сжатие. Я проверял фиксацию, извлечение, обновление и слияние, и время невидимо для меня. К счастью, я сэкономил много места на диске.