Subversion отмечает немодифицированные файлы как измененные

Здесь возникает нечетная проблема с использованием Subversion: при слиянии с веткой разработки на магистраль (или обратно, если на то пошло) Subversion будет отмечать множество файлов как измененных - в то время как у них не было никаких изменений.

Вот что происходит:

В моей ветке я фиксирую 1 измененный файл
В trunk я сливаюсь в том, что commit
Многие другие файлы и каталоги помечены как "измененные" без фактического изменения (даже без пробелов, окончаний строк, свойств или такого рода материалов).

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

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

FYI: клиент subversion в диапазоне 1.6.x, сервер в диапазоне 1.5.x. Используя комбинацию Versions.app и CLI в Mac OS X Leopard.

Ответ 1

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

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

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

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

Это, похоже, было зафиксировано в SVN 1.7. Из примечаний к выпуску: Изменено изменение mergeinfo поддерева.

Ответ 2

Изменение в свойствах файла. Если вы запустите svn proplist, вы увидите много записей mergeinfo. Это связано с тем, что треки svn сливаются в свойствах файла. Это новая функция от 1.5, поэтому она не встречалась в более старых версиях.

Я никогда не понимал точно, почему это происходит, но это связано с прорывом внутренней реализации. Попытка понять это, не понимая, как svn реализована, является, насколько я понял, невозможной. Однако обычно основная причина связана с слиянием поддерева. Например. Если вы объедините изменения подкаталога или одного файла, а не весь ветвь/тег. Чтобы отслеживать, что было объединено, subversion поместит свойство mergeinfo в самый общий node, но, по-видимому, он недостаточно интеллектуальный, чтобы выбрать его. Вы можете устранить проблему, вручную отредактировав mergeinfo. Просто удалите свойство из всех узлов ниже соединительной линии и убедитесь, что соединительная линия имеет все объединенные ревизии в своем mergeinfo. Конечно, это означает, что вы должны убедиться, что изменения действительно были объединены.

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

Ответ 3

Это может быть какое-то изменение свойства, возможно, автоматическая модификация атрибута svn: mergeinfo. Вы можете определить, является ли это модификацией свойства, запустив "svn stat". Если "M" находится в первом столбце, он изменяется в содержимом, если он во втором столбце, это свойство изменяется.