Обновленный файл не будет зафиксирован

Question

Многие исправления назад, хороший файл в моем репозитории SVN был перезаписан. Версия 10, скажем, содержит файл samplefile.txt в его желаемой форме; текущая версия 30.

я обновить мою рабочую копию с пересмотром 10 samplefile.txt:

$ svn update -r 10 samplefile.txt 

Я подтверждаю, что моя рабочая копия файла имеет это старое, но желаемое содержание в нем. Теперь я хочу передать этот файл в репо, образуя версию 31.

$ svn commit -m "reverting file to 10" samplefile.txt 

Это никогда не совершает. Выполнение команды возвращает меня в приглашение терминала без обычного вывода SVN, который подтверждает новую ревизию, а обновленный файл не отображается в репозитории.

Как передать этот контент с помощью команд SVN?

Answer 1

Попробуйте это:

svn update samplefile.txt 
svn cat -r 10 samplefile.txt > samplefile.txt 
svn commit -m "reverting file to 10" samplefile.txt 

Answer 2

Вы должны выполнить следующую команду в вашей рабочей копии:

svn merge ^/trunk . -c-10 

И совершить это изменение:

svn commit -m "Revert changes made in r10" 

Read SVNBook | Undoing Changes.

Answer 3

Как svn merge Работы

Команда svn merge используется несколькими различными способами, но в основном она всегда делает две вещи в последовательности: 1) создать диф путем сравнения двух источников, и 2) применять этот diff к цели.

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

В общем, то, командная строка вызова имеет вид

$ svn merge [create diff] [apply to target] 

Более подробно,

1) [создать дифференциал]

svn merge сравнивает источник А и источник B для создания diff, который представляет собой набор инструкций, необходимых для преобразования источника A в источник B.

Источниками могут быть любые элементы набора файлов: соединительная линия или ветвь, поддерево каталога или отдельный файл. Источником может быть либо элемент рабочей копии (в этом случае он идентифицируется по его файловому пути), либо элемент самого хранилища (в этом случае он идентифицируется URL-адресом репо). Источник может ссылаться на любую ревизию репозитория; если ревизия не указана, обычно предполагается самая последняя ревизия (HEAD).

2) [обратиться к целевой]

После дифф создается, merge затем применить этот набор инструкций к цели. Цель должна быть быть элементом рабочей копии; команда merge обычно считается выполненной из этой рабочей копии.

Очевидно, что если цель не имеет никакого отношения к двум источникам, используемым для создания диф, то вы просто получите нонсенс, когда дифференциалов инструкции к нему применяются. Цель также должна быть тем же «типом вещей», что и два источника; то есть, если diff сравнивает две ветви или ветку/туловище, то цель также должна быть либо ветвью, либо туловищем. Если этими двумя источниками являются файлы, то целью должен быть файл и т. Д.

Именно поэтому команды merge должны быть сконструированы тщательно. Не слишком сильно потейте, потому что цель должна быть элементом вашей рабочей копии, merge может повлиять только на рабочую копию, а не на репо. Пока вы не commit, не проверяя результат merge, достаточно легко исправить, если вы ошиблись merge.

Обратный сливается

А «обратного слияния», чтобы вернуться файл является формой cherry-pick merge, который принимает два различных ревизий одного элемента в виде двух его источников. Таким образом, мы указываем только одно имя источника в командной строке, сопровождаемое -r или -c флагами, чтобы сказать, какие из двух версий будут источниками.

Флаг -r определяет его как абсолютное число N или как диапазон N:M.

Флаг -c указывает изменение сделана ревизия. Это полезно в некоторых случаях, но не в этом, потому что разница между текущим файлом (rev 30) и желаемым файлом (rev 10) охватывает множество изменений более чем в 20 разных версиях - я не хочу возвращать одно изменение, но целых двадцать!

С точки зрения моей гипотетической samplefile.txt,

[create diff] = -r 10:30 <URL of repository>/path/to/samplefile.txt 

производит набор инструкций, преобразующая samplefile.txt@10 к samplefile.txt@30. Это не то, что я хочу, однако - я хочу наоборот, набор инструкций, который принимает текущий samplefile.txt@30 обратно в samplefile.txt@10. Это может быть определено путем изменения числа оборотов, т.е.

[create diff] = -r 30:10 <URL of repository>/path/to/samplefile.txt 

Это то, что делает его «обратного слияния». (Обратите внимание, что флаг -r не имеет ничего общего со словом «reverse».)

Моя цель файл samplefile.txt в моей рабочей копии, или

[apply to target] = WC_root/filepath/to/samplefile.txt 

Поскольку дифф построен принять samplefile.txt@30 ->samplefile.txt@10, копия в моей рабочей копии должна быть последняя версия (оборот 30). Это важно проверить, потому что я ранее обновлял файл до версии 10 в интуитивно понятной, но по какой-то причине бесполезной попытке передать этот контент обратно в репозиторий как ревизию 31. Итак, всегда обязательно перед merge команда.

Откат файл с помощью обратного слияния

Ввод [create diff] и [apply to target] вместе, команда для возврата samplefile.txt из его содержания оборотов 30 к его содержанию оборотов 10 с использованием обратного слияния является

$ svn update 
$ svn merge -r 30:10 <URL of repository>/path/to/samplefile.txt WC_root/filepath/to/samplefile.txt 

Если все проверяется, а текущее содержимое samplefile.txt действительно соответствует редакции 10, то я теперь передаю репо:

$ svn commit -m "reverting file to rev 10" WC_root/filepath/to/samplefile.txt 

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

Ссылки:

Лучшая общая документация я мог бы найти о том, как merge команда определяется дается в SVN книгу здесь: Merge Syntax

Ручные секции, соединенные @bahrep дать несколько примеров о том, как вы можете использовать merge для выполнения различных задач. (Я не могу повторить ссылки здесь, потому что это меня лишает 2-х лимитный лимит.)

И, конечно, есть svn help merge, что будет намного понятнее после прочтения этих ссылок (и, надеюсь, этот ответ).

Большое спасибо @alroc и @bahrep за то, что помогли мне разобраться в этом!