Нечетные сообщения об ошибках обратного слияния SVN - PullRequest
Новая
       28

Нечетные сообщения об ошибках обратного слияния SVN

1 голос
/ 20 декабря 2011

Попытка обратного слияния для восстановления 1 конкретного файла. Мне кажется, я понимаю, как это должно работать, но получаю странные ошибки.

Я перечитал svn book, Google и стек и т. Д.

Проблема:

Я хочу указать 1 конкретный файл для восстановления.

SVN не нравится ссылка на локальный файл, потому что файл не существует, но в сетевых примерах, похоже, используется имя локального файла.

Ему также не нравится полный http-путь, потому что он не существует в хранилище. Я знаю, что это не существует сейчас, но это было там. Даже использование синтаксиса @peg по-прежнему выдает ошибку.

Пример:

  • В ревизии 100 Я удаляю кучу файлов, поэтому r99 был последним моментом его существования.
  • Сейчас мы находимся в редакции 150 , и я хочу вернуть только один файл.
  • Допустим, файл называется .myFile (с начальной точкой, не думаю, что это имеет значение)
  • URL проекта и "рабочий каталог" - http://server/repo/Project/trunk
  • URL файла был бы http://server/repo/Project/trunk/.myFile
  • Предположим, я нахожусь в каталоге эквивалентной файловой системы, без ожидающих обновлений или фиксаций, другими словами svn status --show-updates. показывает, что я в курсе.
  • А я умею делать svn cat http://server/repo/Project/trunk/.myFile@99

Неудачные попытки: 

svn merge -c -100 .myFile
Error: .myFile not under version control

svn merge -c -100 http://server/repo/Project/trunk/.myFile
Error: svn: '/repo/!svn/bc/120/Project/.myFile' path not found
Note that rev 120 is between the delete (r100) and now (r150)

svn merge -c -100 http://server/repo/Project/trunk/.myFile@99
Error: svn: File not found: revision 100, path '/Project/trunk/.myFile'

svn merge -c -100 . .myFile
Don't recall specific error.

svn merge -c -100 . http://server/repo/Project/trunk/.myFile@99
Error: svn: Cannot specify a revision range with two URLs

... и различные другие комбинации ....

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

У меня есть обходные пути: я могу восстановить все файлы, а затем очистить. Или просто скопируйте и вставьте старую версию, я мог бы сделать это с помощью команды svn cat.

Но я бы хотел понять «правильный» путь.

1 Ответ

1 голос
/ 24 апреля 2012

Работая над немного другой проблемой сегодня, я думаю, что наконец нашел свой ответ.

Я объединял изменения из отдельного файла с восстановлением удаленной копии, так что это не совсем то же самое.

Одно ключевое изменение, которое я сделал:

  • Я использовал явный диапазон -r ИЗ: TO вместо простого сочетания клавиш -c.

Другие пункты:

  • источник должен быть в форме URL
  • место назначения должно быть в локальной форме ./filename

Гипотетический пример пересмотра ревизии:

  • В настоящее время система имеет вид r150
  • Файлы были удалены в r100
  • Файлы в последний раз присутствовали в r99 (хотя и не были изменены)
  • Файлы былипоследнее добавление / обновление в r85
  • Примечание: мой пример имени файла - скрытый файл Unix, поэтому он начинается с точки - большинство файлов не имеют этого.

Отмена удаления, ядумаю, что это будет: 

cd localWorkDir/Project/trunk
svn update
svn merge -r100:85 http://server/repo/Project/trunk/.myFile ./.myFile
svn commit -m "restoring files"
(message saying committed r151)

Так что я думаю, что синтаксис -c при объединении отдельных файловпроблематичный.

...