Функция Obliterate Subversion

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

Вот что я имел в виду:

На клиенте

svn list -R > file-list.
фильтровать список файлов несколькими способами, например grep, для создания файла "файлы для удаления", что-то вроде набора grep XXX file-list>>files-to-delete.
передать files-to-delete на сервер с помощью scp.

На сервере

Дамп репозитория svnadmin dump /path/to/repos > repos-dumpfile, это также можно сохранить в качестве резервной копии.
Отфильтруйте файл дампа, для каждого слова в файлах для удаления, выполните: cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
Создайте новый репозиторий и загрузите в него новый файл svnadmin create new-name; svnadmin load new-name < new-dumpfile

Будет ли это работать? Как это может произойти? Любые другие идеи?

Ответ 1

Да, этот script будет работать. Но обычно вы не уничтожаете много файлов. Обычно уничтожение необходимо только в том случае, если вы произвольно передаете конфиденциальную информацию.

Вы действительно хотите использовать стирать для большого количества файлов?

Ответ 2

Я думаю, что cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile - опасный пример. new-dumpfile не будет полностью обработан, и содержимое будет вероятно потеряно, no?

Из комментариев ниже: новый-dumpfile, несомненно, будет потерян, потому что оболочка будет clobber (обрезать до нулевой длины) даже до запуска команды.

Ответ 3

У меня было подобное, но несколько более сложное требование. Несколько сотен ревизий в прошлом, некоторые очень большие ( > 1 ГБ) образцы файлов данных были переданы в репозиторий. Затем они были перемещены и в конечном итоге удалены из HEAD. Однако они все еще находились в истории ревизий, делая хранилище громоздко большим. Я не мог использовать svn list -R, так как файлы больше не появлялись в рабочей копии.

Однако svn list может быть задан аргумент ревизии. Я не был уверен точно, когда большие файлы были проверены, но я знал, что это было после пересмотра 2000. У меня также был список имен файлов. Поэтому я использовал простой цикл и uniq для генерации моего files-to-delete:

cd $working_copy
for rev in {2000..2437}; do
    svn ls -R -r$rev | grep -f ~/tmp/big-file-names >> ~/tmp/file-paths;
done
cat ~/tmp/file-paths | sort | uniq > ~/tmp/files-to-delete
cd ~/tmp
# You should inspect "files-to-delete" to see if it looks reasonable!
cat dumpfile | svndumpfilter exclude `cat files-to-delete` > dumpfile.new

Ответ 4

Как насчет файлов с одним и тем же путем в разных версиях? Например, если вы зафиксируете /trunk/foo, переименуйте его в /trunk/bar, а затем зафиксируйте что-то еще в /trunk/foo, которое вы хотите уничтожить. Вы не хотите потерять историю того, что сейчас /trunk/bar. Может быть, svndumpfilter поддерживает peg revisions?