Функция Subversion Obliterate - PullRequest
Новая
       61

Функция Subversion Obliterate

22 голосов
/ 18 февраля 2009

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

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

На клиенте

  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 ]

7 голосов
/ 18 февраля 2009

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

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

6 голосов
/ 19 марта 2009

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

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

4 голосов
/ 16 декабря 2010

У меня было похожее, но чуть более сложное требование. Несколько сотен ревизий в прошлом, некоторые очень большие (> 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
0 голосов
/ 25 января 2010

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

...