Функция Subversion Obliterate

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

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

На клиенте

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

На сервере

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

Будет ли это работать? Как это может потерпеть неудачу? Есть другие идеи?

Источник

4 ответа

Решение

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

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

Источник

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

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

Источник

У меня было похожее, но чуть более сложное требование. Несколько сотен ревизий в прошлом, некоторые очень большие (>1 ГБ) образцы файлов данных были переданы в хранилище. Затем они были перемещены и в конечном итоге удалены из головы. Однако они все еще были в истории изменений, что делало хранилище громоздким. Я не мог использовать 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
Источник

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

Источник
Другие вопросы по тегам