#svn #version-control
#svn #контроль версий
Вопрос:
У меня есть репозиторий SVN на основе файлов, размещенный в облаке. Каким-то образом мне удалось зафиксировать ревизии 5001, 5002 и 5003 вчера поздно вечером, попытаться зафиксировать 5004 сегодня … только для того, чтобы он настаивал на том, что rev 5001 не существует. Я сильно подозреваю, что моя облачная синхронизация перезаписала или удалила файлы, но я не могу найти основу для восстановления того, чего не хватает.
Довольно ясно, что в репозитории / db / revs существуют все обороты до 5000, как и 5002 и 5003, но 5001 отсутствует. Я точно знаю, как был сгенерирован этот rev — есть ли какой-либо способ восстановить его из задействованных файлов? Могу ли я, возможно, создать дубликат репозитория, выполнить откат до 5000, а затем снова зафиксировать файлы или что-то в этом роде?
Обновление: выполнение инструкций TortoiseSVN относительно возврата к предыдущим версиям (например, 5000) не работает — они приводят к ошибке: нет такой ревизии 5001. Эти инструкции рекомендуют не использовать svnadmin/svndumpfilter … но это выглядит как единственный жизнеспособный вариант.
Комментарии:
1. Можете ли вы увидеть свои недостающие изменения ревизии в списке мертвых транзакций?? Для этого вам нужно перечислить все мертвые транзакции по команде
svnadmin lstxns repo, а затем использоватьsvnlook info repo -t transactionid2. Да и нет — оказывается, все папки транзакций были датированы 3 декабря (12/3)… но транзакции, которые я просматривал, были 2/12 — 12 февраля, а не 2 декабря. Путаница в формате даты привела к тому, что я облаял неправильное дерево, пока, наконец, не получил правильный синтаксис svnlook .
3. Можете ли вы также проверить, выполняется ли команда
svnadmin verify pathс ошибкой? Если команда проверки завершается неудачно, у вас, к сожалению, нет другого выбора, кроме как отказаться и сбросить имеющиеся у вас проверки в новое репозиторий.4. Да, к такому выводу я пришел. В основном процесс был простым, хотя и незнакомым.
Ответ №1:
Ответ был прост: использовать svnadmin dump для создания дампа репозитория. Поскольку процесс дампа начинается с версии 1, он сбрасывает все допустимые ревизии, а затем не добавляет недопустимую ревизию в дамп. Затем из дампа можно было бы создать новое репозиторий и воссоздать последующие изменения.
Многие другие параметры svn, похоже, работают в обратном направлении по сравнению с редакцией HEAD, что приводит к сбою в этом случае.