Как мне сказать Subversion всегда выбирать мою локальную версию для конфликтующих слияний в конкретном файле?

Question

Я ищу способ указать, что подмножество файлов не должно изменяться при объединении изменений из определенной ветви с использованием Subversion. Я нашел кого-то, кто задавал тот же вопрос, , но для git .

У меня есть файлы Maven pom.xml, которые создаются при создании и обновлении ветви для каждого выпуска из ветви. Когда я объединяю изменения обратно в транк из ветви, я не хочу, чтобы изменения в этих файлах были объединены (и они всегда будут конфликтовать, так как номера версий также обновлялись в транке). Есть ли способ сказать Subversion принять базу только для этих файлов, для того же эффекта, что и в ответе на вопрос git ?

Кто-то еще задал аналогичный вопрос , но поместил его в контекст, в котором был задан неправильный вопрос (сгенерированный код).

Answer 1

Решение в моем проекте: у вас нет этого файла в Subversion, т.е. включите его в svn: ignore.

Если вы все еще хотите поделиться файлом, вы можете получить его копию, например pom-example.xmlпод контролем версий.Для центрального файла, такого как pom.xml, может быть приемлемым, что разработчики должны скопировать файл в настоящее имя файла после новой проверки.

Answer 2

Вы можете с помощью скрипта установить свойство svn:mergeinfo в файле, чтобы оно пропускало изменения, сделанные в ветви. (См. http://svnbook.red -bean.com / ru / 1.7 / svn.branchmerge.advanced.html # svn.branchmerge.advanced.blockchanges )

Когда я объединяю проекты maven, я использую TortoiseSVN и отменяю изменения в pom, сделанные плагином релиза, чтобы он не пытался объединить изменения версии. Конечно, я также хочу, чтобы другие изменения в pom были объединены, так как большинство этих изменений являются изменениями зависимостей, и я хочу, чтобы trunk получил эти новые обновления зависимостей.

Answer 3

Если вы знаете, что файлы всегда будут конфликтовать, вы можете запустить svn merge с опцией '--accept mine-full', которая должна гарантировать, что все конфликты будут разрешены путем принятия текущей версии в вашей ветке.

Edit:

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

Другим альтернативным подходом было бы вообще не включать эти файлы в систему контроля версий, а генерировать их автоматически как часть вашей сборки и сохранять информацию о том, какие номера версий находятся в каждой ветви, в другой форме, например, LDAP или Mysql и сгенерируйте их как часть процесса оформления заказа или сборки. Мы используем этот подход (хотя с небольшой разницей, что мы объединяем эти изменения, но содержимое файла в любом случае перезаписывается при каждой сборке, поэтому вам все равно, какие конфликты возникают).