Репозиторий Tortoise SVN поврежден - можем ли мы зафиксировать рабочую копию в более старую резервную копию репозитория?

К сожалению, наш репозиторий tortoiseSVN сегодня был поврежден из-за сбоя на диске.

У нас есть хорошая рабочая копия, основанная на ревизии 2897. Наше последнее хранилище резервных копий относится к ревизии 2848.

Мы хотели бы спасти как можно больше истории, а не создавать новое хранилище.

Итак, можем ли мы сделать это, зафиксировав рабочую копию непосредственно в старом репозитории резервных копий?


repository svn corrupt tortoisesvn
person user482184    schedule 20.10.2010    source источник
comment
Обратите внимание, что SVN book описывает методику, при которой ловушка после фиксации создает инкрементные резервные копии. Теперь, когда вас однажды укусили, вы можете реализовать это. (Конечно, мы все знаем, что если вы сделаете это, и это действительно сработает, этого больше никогда не повторится, но если вы этого не сделаете или возникнет проблема с тем, как вы это сделаете, следующий диск обязательно сделает это. это снова. :)) О, и, кстати, я с thedev по этому поводу (+1 от меня), хотя SVN может пожаловаться на местный номер ревизии.   -  person sbi    schedule 21.10.2010
comment
Дополнительные резервные копии не являются защитой, если они не сохранены на другой диск. Рассмотрите возможность использования svnsync для зеркалирования изменений в удаленной теплой резервной копии или чего-то более сложного, например, функции прокси-сервера для записи.   -  person Mark O'Connor    schedule 21.10.2010
comment
@Mark: Кто сказал, что эти инкрементные дампы нужно делать на один и тот же диск? :) Но, да, это важное замечание. Обратите внимание, что вы можете активировать svnsync из ловушки после фиксации.   -  person sbi    schedule 21.10.2010

Ответы (3)


arrow_upward
2
arrow_downward

Если я ничего не упускаю, я не вижу проблем в таком коммите. Только то, что у вас не будет подробностей истории коммитов между двумя ревизиями.

person thedev    schedule 20.10.2010
comment
SVN может икать из-за того, что рабочая копия имеет более высокий номер ревизии, чем репозиторий. Если это так, вы можете удалить .svn папки из (копии) имеющейся у вас рабочей копии и скопировать ее при новой проверке. Однако при этом будут потеряны любые изменения, кроме внесенных в код (например, свойства). - person sbi; 21.10.2010

arrow_upward
1
arrow_downward

Это случилось и со мной , Мне пришлось проверить новую копию, так как svn сильно задела, когда моя локальная версия была новее, чем сервер. После получения новой копии скопируйте файлы из того, что у вас было локально, поверх новой копии (убедитесь, что вы не копируете папки .svn) и зафиксируйте. Вы потеряете историю между 2848 и 2897 годами.

person rlovtang    schedule 20.10.2010

arrow_upward
0
arrow_downward

Вы потеряли свою историю коммитов, начиная с ревизии 2848. Рабочие копии Subversion сохраняют только локальное состояние ....

В зависимости от того, как вы восстанавливаете свой репозиторий, вы также можете столкнуться с проблемами фиксации из-за неправильного соответствия UUID репозитория. svn-переключатель Команда может использоваться для обозначения смены репозитория. Другой вариант - использовать tortoiseSVN, чтобы создать патч изменений, начиная с версии 2848, и применить его к новой проверке.

person Mark O'Connor    schedule 20.10.2010
comment
Обратите внимание, что патч не будет иметь никаких изменений, кроме кода (свойств и т. Д.), Убедитесь, что таким образом вы не потеряете что-то важное. - person sbi; 21.10.2010
comment
Ваш комментарий об изменениях собственности сделан правильно. Посмотрим правде в глаза, что невозможно полностью и честно построить репозиторий из кассы. Одним из преимуществ систем DVCS, таких как Git, является то, что они хранят всю историю локально. - person Mark O'Connor; 21.10.2010