Обнуление огромного файла в репозитории svn

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

К сожалению, я работаю с людьми! Кто-то, вероятно, когда-нибудь случайно совершит бинарный халк 800 МБ. Это замедляет операции репозитория.

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

Есть ли способ действительно удалить этот файл монстров и получить репозиторий приличного размера? Я попробовал svnadmin dump/load thing, но это было боль.

Ответ 1

Некоторые дополнительные сведения об этом можно найти в сообщении в блоге: Subversion Obliterate, отсутствующая функция

Обязательно прочитайте также комментарии, где Карл Фогель ставит статью в поле зрения: -)

Ответ 2

Чтобы окончательно удалить файлы монстров из репозитория svn, другого решения нет, кроме использования svnadmin dump/load. (SVN Book: команда dump)

Чтобы предотвратить использование огромных файлов, можно использовать hook script. Например, вы могли бы использовать script, который выполнял "pre-commit", когда кто-то пытался зафиксировать репозиторий. script может проверять размер файла или тип файла и отклонять фиксацию, если в нем содержится файл или файлы, которые были слишком большими или "запретный" тип.

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

Крючок script - это script, который запускается в ответ на ответ на события репозитория (Книга SVN: создайте крючки).

Ответ 3

Если вы можете поймать его, как только это произойдет, метод svnadmin dump/load не слишком болезнен. Предположим, что кто-то случайно совершил ошибку bormundous-raw-image.psd в редакции 3849. Вы можете сделать это:

svnadmin dump /var/repos -r 1:3848 > ~/repos_dump

Это создало бы файл дампа, содержащий все до и включая Редакцию 3848. В этот момент вы могли бы использовать svnadmin create и svnadmin load для восстановления репозитория без оскорбительной фиксации, оговоркой в том, что любые изменения, внесенные вами в репозиторий структура каталогов - перехватчики, символические ссылки, изменения разрешений, файлы auth и т.д. - необходимо скопировать из старого каталога. Здесь приведен пример оставшейся сессии bash, которую вы можете использовать для завершения операции:

svnadmin create /var/repos-new
svnadmin load /var/repos-new < ~/repos_dump
cp -r /var/repos/conf /var/repos-new
cp -r /var/repos/hooks /var/repos-new
mv /var/repos{,-old} && mv /var/repos-new /var/repos

Я уверен, что это будет более болезненно, чем больше история вашего репозитория, но она работает.

Ответ 4

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