Откатывайте или вернитесь весь репозиторий SVN к более старому пересмотру

"Обратное" слияние может быть тем, в чем Вы нуждаетесь. См. "отменять изменения" раздел книги svn.

, Например, svn объединяют-r 28:24 [путь к svn]

Если действительно необходимо вытереть 'доказательство', что файлы когда-либо существовали, необходимо сделать svndump/svnload действия, описанные выше.

В 'нормальной' ситуации, где Вы сделали ошибку, необходимо использовать обратное слияние. Это удостоверяется, что, отменяя изменения после того, как r24 может также вернуться, diffed, и т.д.

, команда ниже должна работать для отмены изменений (необходимо фиксировать результат слияния отразить слияние в репозитории)

svn merge -r 28:24

Я очень не хочу сказать это, но который является ситуацией, где я использовал резервные копии своего репозитория SVN.

можно ли скопировать файлы определенного пересмотра нового каталога в репозитории?

вот то, как я начал бы делать это. Жестокий, да, но это - единственная вещь, которая, как гарантируют, полностью проигнорирует коллизии , и сохраняют историю изменений в целости.

  cd /scratchdir 
  svn co -r good svn://repository
  cd /hosed_project
  svn up -r HEAD
  cat >> /tmp/cp.sh 
  ORIG=$1
  TARG=$( echo $ORIG | sed 's/\/scratchdir\///' ); 
  cp $ORIG /hosed_project/$TARG;
  ^D
  chmod u+x /tmp/cp.sh
  find /scratchdir -not -wholename "*/.svn*" -exec /tmp/cp.sh {} \;

Примечание, это не "нормальный" путь IMO, нормальный путь состоит в том, чтобы создать ответвление из старой версии, и затем объединиться, то ответвление въезжают задним ходом голове. (по крайней мере, это - то, как Это использовало для работы)

Редактирование: вышеупомянутый код не тестируется, НЕ выполняйте его verbatim

Я не совсем уверен, примерила ли эта работа, поскольку я еще не использовал ее в живом производстве, но мне сейчас, тестовый репозиторий (я скопировал один из своих производственных), и это кажется для работы.

, Когда Вы будете в своем репозитории, используйте следующую команду:

svn update -r 24 trunk

, Где 24 число пересмотра, и , соединительная линия является файлом/папкой, который требуется обновить (или восстановление, в этом случае) к упомянутому числу пересмотра.

В моем тесте, несколько файлов были обновлены и (пере-) добавленный, и после выполнения фиксации, я не получил предупреждений вообще. Я тогда изменил файл с некоторым фиктивным текстом и попробовал еще одну фиксацию, и только сказал, что файл открылся в измененном списке. Таким образом, это, кажется, работает скорее хорошо!

Снова, я не использовал это прежде в живом производстве, поэтому если я неправ совет. Я хотел бы знать - ли это способ пойти также, потому что я вижу, что я нуждаюсь в этом в (почти) будущее.

-Dave

Можно сделать новый контроль конкретного пересмотра. http://svnbook.red-bean.com/en/1.1/re04.html

svn co path/to/my/repo -r 24

Если структура папок Вашего приложения не изменила, контроль старый пересмотр и заменяет .svn папки от последнего пересмотра в проверенный старый пересмотр. Теперь можно фиксировать "более старую" версию.

Если Вы действительно хотите полностью удалить файлы из репозитория, необходимо сделать svndump в файл, отфильтровать версии и/или пути к файлам, Вы не хотите, делаете новый repo и svnload фильтрованный дамп в новый репозиторий. Вы захотите тщательно читать книжный раздел SVN по обслуживанию репозитория , прежде чем Вы сделаете любое из этого и удостоверитесь, что не удаляете существующий repo, пока Вы не уверены, что новый имеет материал, который Вы хотите.

Если у вас есть доступ к серверу SVN, вы можете просто отредактировать путь / db / current , указав старый номер версии, к которой вы хотите вернуться (здесь: 24) там и удалите ненужные файлы ревизий (например, 25, 26, 27, 28) из пути / db / revs / 0 / . По крайней мере, это сработало у меня сегодня, после того как я случайно удалил каталог в репозитории.

Если вы не пользуетесь правами администратора, вы не можете стереть старые ревизии, НО вы все равно можете очень хорошо скрыть их с помощью всего одной удивительно простой команды «svn copy» (nickf и JesperE уже упоминали об этом, но довольно загадочно)

svn удалить протокол://svnserver/some/resource
svn copy protocol://svnserver/some/resource@24 protocol://svnserver/some/resource

И все, ревизии с 25 по 28 полностью исчезли из журнала svn. Это вовсе не взлом, это безопасная и (едва ли...) задокументированная функция.

Если "ресурс" является каталогом, вы должны удалить его из последнего URL:

svn copy protocol://svnserver/some/directory@24 protocol://svnserver/some/

(иначе скопировал бы его внутрь себя)