Nuking огромный файл в хранилище SVN

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Это создаст файл дампа, содержащий все, вплоть до Revision 3848. В этот момент вы можете использовать svnadmin create и svnadmin load для восстановления хранилища без оскорбительного коммита, поскольку все изменения, сделанные вами в хранилище, могут структура каталога - хуки, символические ссылки, изменения прав доступа, файлы аутентификации и т. д. - необходимо скопировать из старого каталога. Вот пример остальной части сеанса 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

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

Answer 4

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