У нас довольно строгая политика в отношении нашего репозитория subversion, что также является большим неудобством. В наших ветках все, что проверяется на подрывную деятельность, должно иметь отредактированные учетные данные для аутентификации (например, база данных, учетные записи пользователей и т. Д.). Файл был добавлен и зафиксирован как с именами, так и с паролями. Существует три версии этого xml-файла:
Первый - Файл был добавлен и зафиксирован с некоторым несоответствующим (к этому вопросу) содержанием.
Второй - Файл (среди трех других нерелевантных файлов) был зафиксирован с учетными данными аутентификации как часть совершенно нового блока XML.
Третий - Были добавлены и проверены другие файлы, ни одна из которых не является более новой версией плохого файла из предыдущей версии.
Четвертый - Один неверный файл был снова зарегистрирован с удаленными учетными данными для аутентификации (в частности, ни с чем другим).
Я хотел бы удалить вторую редакцию, и, поскольку это первый случай, когда это происходит, мне никогда раньше не приходилось с этим сталкиваться. Я знаю, что с подрывной деятельностью сложно, поскольку цель программного обеспечения - поддерживать ваши версии кода, а не отбирать и вносить изменения в старые версии. Возможно ли удалить один файл из предыдущей ревизии или перезаписать его содержимым новой ревизии (т.е. заменить плохой файл из второй ревизии файлом из четвертой)?
В настоящее время нет obliterate функциональность в Subversion. Это обсуждалось несколько раз, но это нарушает целостность репозитория и еще предстоит реализовать.
ПРЕДУПРЕЖДЕНИЕ: Эта ссылка обсуждается в течение 11 лет. svn obliterate.
Обходной путь - создать резервную копию репозитория с помощью svnadmin dump (ССЫЛКА НА САЙТ), а затем восстановите репозиторий, используя svndumpfilter (ССЫЛКА НА САЙТ) предотвращение добавления конкретных ревизий в восстановленный репозиторий.
Вы можете сделать это с помощью небольшого творческого редактирования файла дампа. Прежде всего, вам нужно выгрузить свой репозиторий, используя
svnadmin dump repolocation > file.dump
Вам нужно открыть файл file.dump в текстовом редакторе и найти ревизию, в которую был добавлен файл. Найдите номер версии: xxx, где xxx - это версия, в которую был добавлен второй файл. Ниже вы найдете такой блок, как
Node-path: trunk/my/file1.txt
Node-kind: file
Node-action: change
Text-content-length: 14
Text-content-md5: c0bf20e1c2a520acddd3fccc2b9c5781
Text-content-sha1: 83162b1f0ca7b6e6816d2bc8f44550915fa2f4b7
Content-length: 14
contentsinfile
Если вы удалите указанный выше блок, файл дампа должен по-прежнему работать, и это будет похоже на то, что второй файл никогда не добавлялся в репозиторий, когда вы загружаете файл дампа в новый репозиторий.
Однако, если вам нужно, чтобы файл отображался (поскольку он потенциально содержал некоторые другие изменения, вам необходимо сделать следующее.
Там, где я показываю содержимое файла выше, вы найдете содержимое второго зафиксированного файла, включая пароли. Вы должны отредактировать пароли, но сохранить длину текста такой же! Это сделано для того, чтобы параметры Content-length и Text-content-length были правильными! (Вы также можете отрегулировать длину, но вы ищете больше проблем) Однако проблема в том, что контрольные суммы md5 и sha1, которые вы видите выше, не совпадают. Вам нужно будет сгенерировать новые md5 и sha1 на основе измененного содержимого файла, что может быть довольно сложно, но не слишком сложно!
Как только вы закончите редактирование, вам необходимо загрузить измененный файл дампа в новый репозиторий.
svnadmin create newrepo
svnadmin load newrepo < file.dump