Есть ли способ отключить TortoiseSVN с помощью svn: mergeinfo?

Question

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

Изменяет свойство svn:mergeinfo.

Есть ли какая-либо причина, почему эти свойства, установленные в каталоге / файлах, необходимы? Есть ли способ обойтись без внесения этих изменений в svn:mergeinfo?

Обычно я просто возвращаю предметы, а затем фиксирую, но это тратит дополнительное время.

Answer 1

Скорее всего, это происходит, потому что эти файлы и каталоги имеют свойство svn: mergeinfo, установленное из предыдущего слияния. Я не думаю, что это хорошая идея - объединять отдельные файлы или каталоги так, чтобы запись mergeinfo записывалась в отдельные файлы. Вы должны привыкнуть к слиянию на максимально возможном для вашего рабочего уровня уровне, чтобы свойство mergeinfo устанавливалось только для структурных каталогов, таких как / trunk или /branches/1.0.

.

Однако, если вы обнаружите, что у вас есть свойства mergeinfo для отдельных файлов и папок, вы можете сделать две вещи: во-первых, просто удалить свойство svn: mergeinfo из соответствующих файлов и каталогов. Я не уверен, что это рекомендуется, если вы действительно не знаете, что делаете, и каковы могут быть последствия. Прочтите документацию, прежде чем сделать это!

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

Как уже было сказано, я работал со своими товарищами по команде, чтобы выработать правильные привычки, чтобы у нас больше не было этого раздражения.

Answer 2

SVN 1.7 и более поздние версии

Это должно быть исправлено в SVN 1.7. От примечания к выпуску :

Слияния больше не записывают информацию слияния (описывающую слияние) на поддеревьях (которые имеют свою явную информацию слияния), если на поддерево не повлияло слияние. Это должно значительно уменьшить количество ложных svn:mergeinfo изменений свойств для пользователей, у которых есть большое количество поддеревьев с явным mergeinfo.

SVN до 1,7

Что происходит, когда файл / папка имеет явную mergeinfo, каждый последующее слияние с веткой обновит эту информацию слияния, даже если Файл / папка не связаны. Это раздражает, так как вводит все больше и больше беспорядок в списке изменений для каждого слияния.

Чтобы избежать этого, нужно только слить в «корневую» папку ветки, например "/Branches/maintenance2.x". Ни один из файлов или папок ниже "/branches/maintenance2.x" должен получить mergeinfo. Следуйте совету по слиянию в книге SVN .

К сожалению, даже если вы сливаетесь только в «корневую» папку ветки, пустые svn:mergeinfo свойства могут по-прежнему появляться в отдельных файлах и папки, когда они копируются, чтобы указать, что они не получили такие же, как их братья и сестры.

Вероятно, безопасно удалить лишнее поддерево mergeinfo. Один из способов сделать это - выполнить рекурсивное удаление свойства svn:mergeinfo для каждого файла и папки в корне проекта. (Но сохраняйте mergeinfo в самой корневой папке!)

Кроме того, вы можете обновить до Subversion 1.6 . Я проверил, что это решает эту проблему. Кажется, он даже удаляет лишнюю mergeinfo, добавленную более ранними версиями, для вас.

Судя по комментариям, в SVN 1.6 все еще есть случаи, когда появляется лишнее поддерево mergeinfo. Но я не смог воспроизвести это.

Answer 3

Если вы выполняете слияния с параметром --ignore-ancestry, то свойства mergeinfo не будут созданы в первую очередь.

svn merge --ignore-ancestry -c 1234 svn://sourcecontrol .

Answer 4

Если вы отметите Игнорировать происхождение , он не создаст svn mergeinfo в папках. Если вы уже получили информацию о слиянии SVN, просто верните ее и выполните слияние еще раз, проверив происхождение игнорирования.

Answer 5

svn: mergeinfo - это свойство, которое Subversion использует для отслеживания истории слияния . Я просто позволил бы ему делать то, что он должен делать ... вам может понадобиться отслеживание истории слияний позже и обнаружить, что оно не работает, потому что вы не зафиксировали эти свойства.

Answer 6

Команда, указанная в вопросе переполнения стека Удалите ненужные свойства svn: mergeinfo удалит любую дополнительную информацию mergeinfo.

From the root of the project do:

svn propdel svn:mergeinfo -R
svn revert .
svn ci -m "Removed mergeinfo"

Answer 7

Я бы добавил, что по крайней мере одна часть этой ошибки была исправлена ​​в Subversion 1.5.5. Из файла 1.5.5 ИЗМЕНЕНИЯ :

do not create mergeinfo for wc-wc moves or copies (r34184, -585)

То есть, в SVN до 1.5 была ошибка, из-за которой он создавал записи mergeinfo, которые он не использовал и был излишним, и это, вероятно, то, что исходный спрашивающий задавал, если у них было много svn:mergeinfo свойства.

Answer 8

У нас также была эта проблема в моей команде, и это сделало весь процесс слияния немного запутанным. Прочитав это, я попытался удалить свойство svn: mergeinfo из ряда файлов, и после некоторого дальнейшего тестирования похоже, что это решило проблему.

Answer 9

Отличный вопрос и ответ! В последнее время у нас возникла эта проблема, потому что мы пытаемся обойти ограничения нашей автоматизированной системы сборки. Наша система сборки автоматически увеличивает .bdsproj и некоторые файлы .dpr / .dpk на информацию о версии и пути.

Я хочу это изменить ... но сейчас, если вы хотите объединить одну ветвь с другой, вы получите несколько файлов, которые вы изменили, а затем 1000 файлов, которые изменил сборочный компьютер. Таким образом, мы выполняли «целевые» слияния, иногда по файлу за раз. Особенно с файлами .dpr или .bdsproj, которые имеют законные изменения (например, включение дополнительного модуля). Теперь я знаю, что происходит, поэтому я могу положить конец безумию.

Спасибо, переполнение стека!

Answer 10

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

Пока это не доставило нам никаких проблем. Ведение журнала по-прежнему доступно для файлов и выглядит одинаково (но в любом случае вы делаете это на свой страх и риск!).

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