Когда я выполняю слияние TortoiseSVN, он включает в себя кучу каталогов и некоторые файлы в измененных файлах, даже если фактических изменений нет.
Изменяет свойство svn:mergeinfo.
Есть ли причина, почему эти свойства заданы в каталоге/файлах? Есть ли способ обойти эти изменения без svn:mergeinfo?
Обычно я просто возвращаю элементы, а затем фиксирую, но это лишнее время.
Это происходит очень вероятно, потому что эти файлы и каталоги имеют свойство svn: mergeinfo, установленное из предыдущего слияния. Я не думаю, что в целом хорошая идея объединить отдельные файлы или каталоги таким образом, чтобы mergeinfo записывался в отдельные файлы. Вы должны привыкнуть к слиянию на самом высоком уровне, возможном для вашего рабочего процесса, так что свойство mergeinfo устанавливается только в структурные каталоги, такие как /trunk или/branches/1.0.
Однако, если вы обнаружите, что у вас есть свойства mergeinfo для отдельных файлов и папок, вы можете сделать две вещи: сначала нужно удалить свойство svn: mergeinfo из файлов и каталогов, о которых идет речь. Я не уверен, что это рекомендуется, если вы действительно не знаете, что делаете, и каковы могут быть последствия. Прочитайте документацию, прежде чем делать это!
Вторая вещь, которую вы можете сделать, - это зафиксировать свойство, изменившее способ SVN, к которому вы хотите, что, если вы доверяете программному обеспечению, вероятно, правильно.
Это было сказано, что я работал с моими товарищами по команде, чтобы найти правильные привычки, чтобы у нас больше не было этого раздражения.
Это должно быть исправлено в SVN 1.7. Из примечания к выпуску:
Сливается больше не записывает mergeinfo (описывающий слияние) в поддеревьях (у которых есть свой собственный явный mergeinfo), если поддерево не было затронуто слиянием. Это должно значительно уменьшить количество ложных изменений свойств
svn:mergeinfoдля пользователей с большим количеством поддеревьев с явным mergeinfo.
Что происходит, когда файл/папка имеет явное значение mergeinfo, каждый последующее слияние с веткой обновит этот mergeinfo, даже если файл/папка не имеет отношения. Это раздражает, поскольку оно вводит все больше и больше беспорядок в списке изменений для каждого слияния.
Чтобы избежать этого, просто слейте в корневую папку ветки, например "/branches/maintenance2.x". Ни один из файлов или папок ниже "/branches/maintenance2.x" должен затем получить mergeinfo. Следуйте рекомендациям в книге SVN.
К сожалению, даже если вы слились только в корневую папку ветки,
пустые svn:mergeinfo свойства могут по-прежнему отображаться в отдельных файлах и
если они скопированы, чтобы указать, что они не получили
так же, как и их братья и сестры.
Вероятно, безопасно удалить избыточное поддерево mergeinfo. Один из способов сделать это - сделать рекурсивное удаление свойства svn:mergeinfo для каждого файла и папки в корне вашего проекта. (Но сохраните файл mergeinfo в самой корневой папке!)
Кроме того, вы можете перейти на Subversion 1.6. Я подтвердил, что он исправляет эту проблему. Даже кажется, что вы удаляете лишний mergeinfo, добавленный более ранними версиями для вас.
Судя по комментариям, в SVN 1.6 все еще есть случаи, когда появляется лишнее вспомогательное дерево mergeinfo. Но я не смог воспроизвести это.
Если вы выполняете свои слияния с параметром --ignore-ancestry, тогда свойства mergeinfo не будут созданы в первую очередь.
svn merge --ignore-ancestry -c 1234 svn://sourcecontrol .
Если вы отметите Ignore ancestry, он не будет создавать svn mergeinfo в папках. Если вы уже получили информацию о слиянии svn, просто верните ее и снова выполните слияние, проверив предков ignore.
svn: mergeinfo - свойство Subversion использует историю слияния треков. Я просто позволю ему делать то, что он должен делать... вам может понадобиться отслеживание истории слияния позже и обнаружить, что он не работает, потому что вы не совершали эти свойства.
Команда, приведенная в вопросе. Удалите ненужные свойства svn: mergeinfo, чтобы удалить любую лишнюю mergeinfo.
From the root of the project do:
svn propdel svn:mergeinfo -R
svn revert .
svn ci -m "Removed mergeinfo"
Я бы добавил, что по крайней мере одна часть этой ошибки была зафиксирована в Subversion 1.5.5. Из 1.5.5 CHANGES file:
do not create mergeinfo for wc-wc moves or copies (r34184, -585)
То есть, была ошибка в SVN до 1.5, где она создавала бы записи mergeinfo, которые она не использовала, и была излишней, и это, вероятно, то, что исходный вопросник ударил, если у них было много svn:mergeinfo свойства.
Мы удалили его рекурсивно в наш проект, потому что почти все файлы имели эту информацию, которая делала сливание очень раздражающим (если только один файл был изменен, все файлы должны были быть объединены). Отныне мы будем сливаться только с корнем, что должно избежать этой ситуации в будущем.
До сих пор нам не было никаких проблем. Ведение журнала по-прежнему доступно в файлах и, похоже, одинаково (но делайте это на свой страх и риск!).
О, мы сделали это на нашем багажнике, как раз перед тем, как создать новую ветку. Таким образом, мы можем начать с чистого листа.
Отличный вопрос и ответ! У нас эта проблема возникла в последнее время, потому что мы пытаемся обойти ограничения нашей автоматизированной системы сборки. Наша система сборки автоматически увеличивает файлы .bdsproj и некоторые файлы .dpr/.dpk с информацией о версии и пути.
Я хочу изменить это... но прямо сейчас, если вы хотите объединить одну ветку с другой, вы получите несколько файлов, которые вы изменили, а затем 1000 файлов, которые изменили машина сборки. Таким образом, мы делали "целенаправленные" слияния, иногда файлы за раз. Особенно в файлах .dpr или .bdsproj, которые имеют законные изменения (например, включение дополнительной единицы). Теперь я знаю, что происходит, поэтому я могу надеяться остановить безумие.
Спасибо Stack Overflow!
У нас также была эта проблема в моей команде, и это сделало весь процесс слияния немного запутанным. Прочитав это, я попробовал удалить свойство svn: mergeinfo из нескольких файлов, и после некоторого последующего тестирования похоже, что это решило проблему.