Откат или возврат всего репозитория svn к более старой версии

Я испортил свой репозиторий SVN и теперь должен вернуть весь репозиторий из версии 28 в 24 и не хочу иметь дело с различиями или конфликтами. Есть ли быстрый и простой способ сделать это? Я смог вернуться к отдельным файлам, прежде чем нормально с командой merge - но в этом случае он хочет добавить все файлы обратно в репозиторий из версии 28, когда все, что я действительно хочу сделать, это удалить их.

Я использую командную строку в окне linux (бить.)

спасибо

редактировать

Спасибо за помощь! Я исправил это:

svnadmin create /svnroot/<repo>.fixed
svnadmin dump -r 1:24 /svnroot/<repo> --incremental > dump.svn
svnadmin load /svnroot/<repo>.fixed < dump.svn

затем поместите старое РЕПО в резервную копию и переместите РЕПО.фиксированного РЕПО.

еще раз спасибо!

14 ответов


проверить svnadmin dump и нагрузки. Он создает текстовый файл с каждой версией ваших файлов. Возможно, можно удалить все выше / ниже определенной точки и повторно импортировать его.

см., например,Перенос Данных Репозитория В Другое Место


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

Е. Г. SVN merge-r 28: 24 [путь к svn]


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

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

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

svn merge -r 28:24

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


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

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

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

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

SVN копировать protocol://svnserver/some/directory@24 протокол: / / svnserver / some/

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


для тех, кто использует TortoiseSVN, решение простое:

  • просмотр журнала изменений
  • щелкните правой кнопкой мыши ревизию, к которой вы хотите вернуться...
  • ...выберите "вернуться к этой редакции"
  • зафиксировать изменения

этот метод сохраняет историю версий (т. е. все изменения, что вы вернулись).


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

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

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


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


Я ненавижу это говорить, но это ситуация, когда я обнаружил, что использую резервные копии моего репозитория svn.

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


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

  cd /scratchdir 
  svn co -r good svn://repository
  cd /hosed_project
  svn up -r HEAD
  cat >> /tmp/cp.sh 
  ORIG=
  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, нормальный способ-создать ветвь из старой версии, а затем объединить эту ветвь обратно в голову. ( по крайней мере, так оно и есть!--2 - >используется для работы )

Edit: приведенный выше код не тестировался, не запускайте его дословно!--4-->


не могли бы вы svn del самые верхние каталоги, затем svn copy них:

svn copy svnurl@version svnurl 

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

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

svn update -r 24 trunk

здесь 24 - это номер ревизии, и багажник файл/папку, которые хотите обновить (или восстановить, в данном случае) на указанный номер редакции.

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

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

-Дэйв


Example:
    Rev 100 all is working great        
    Rev 101 somebody really corrupted the dir structure and / or merged in bad changes, etc.
    Rev 102 You delete /trunk
    Rev 103 You copy /trunk@100 to HEAD
        You now have a /trunk that reflects only Rev 100 and 103. Not 101 or 102.

svn del svn://[RepoName]/trunk -m "removing issue in HEAD"
svn copy svn://[RepoName]/trunk@100 svn://[RepoName]/trunk -m "Copy of correct revision of trunk to HEAD"