Есть ли способ отключить TortoiseSVN с помощью svn:mergeinfo?
Когда я выполняю слияние с TortoiseSVN, оно включает в себя несколько каталогов и некоторые файлы в измененных файлах, хотя реальных изменений нет.
Это меняет свойство svn:mergeinfo,
Есть ли какая-то причина, почему эти свойства, установленные в каталоге / файлах, необходимы? Есть ли способ обойтись без внесения этих изменений в svn:mergeinfo?
Я обычно просто возвращаю предметы, а затем фиксирую, но это тратит дополнительное время.
10 ответов
Скорее всего, это происходит потому, что эти файлы и каталоги имеют свойство svn:mergeinfo, установленное из предыдущего слияния. Я не думаю, что это хорошая идея - объединять отдельные файлы или каталоги так, чтобы запись mergeinfo записывалась в отдельные файлы. Вы должны привыкнуть к слиянию на максимально возможном для вашего рабочего уровня уровне, чтобы свойство mergeinfo устанавливалось только для структурных каталогов, таких как /trunk или /branches/1.0.
Однако, если вы обнаружите, что у вас есть свойства mergeinfo для отдельных файлов и папок, вы можете сделать две вещи: во-первых, просто удалить свойство svn:mergeinfo из рассматриваемых файлов и каталогов. Я не уверен, что это рекомендуется, если вы действительно не знаете, что делаете, и каковы могут быть последствия. Прочитайте документацию, прежде чем сделать это!
Второе, что вы можете сделать, это зафиксировать это свойство, изменив способ, которым SVN хочет, чтобы вы, что, если вы доверяете программному обеспечению, вероятно, будет правильным решением.
При этом, я работал со своими товарищами по команде, чтобы получить правильные привычки, чтобы у нас больше не было этого раздражения.
SVN 1.7 и позже
Это должно быть исправлено в SVN 1.7. Из примечаний к выпуску:
Слияния больше не записывают информацию слияния (описывающую слияние) на поддеревьях (которые имеют свою явную информацию слияния), если на поддерево не повлияло слияние. Это должно значительно уменьшить количество ложных
svn:mergeinfoизменения свойств для пользователей, которые имеют большое количество поддеревьев с явным mergeinfo.
SVN до 1.7
Случается так, что как только файл / папка имеет явную информацию 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 .
Если вы установите флажок Игнорировать происхождение, он не создаст svn mergeinfo в папках. Если вы уже получили информацию о слиянии svn, просто отмените ее и выполните слияние еще раз, проверив происхождение игнорирования.
svn:mergeinfo - это свойство, которое Subversion использует для отслеживания истории слияния. Я просто позволил бы ему делать то, что он должен делать... вам может понадобиться отслеживание истории слияний позже и обнаружить, что оно не работает, потому что вы не зафиксировали эти свойства.
Команда, приведенная в вопросе переполнения стека. Удалите ненужные свойства svn:mergeinfo, чтобы удалить любую лишнюю mergeinfo.
Я хотел бы добавить, что по крайней мере одна часть этой ошибки была исправлена в 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 свойства.
Отличный вопрос и ответ! В последнее время у нас возникла эта проблема, потому что мы пытаемся обойти ограничения нашей автоматизированной системы сборки. Наша система сборки автоматически увеличивает.bdsproj и некоторые файлы.dpr/.dpk информацией о версии и пути.
Я хочу это изменить... но сейчас, если вы хотите объединить одну ветку с другой, вы получите несколько файлов, которые вы изменили, а затем 1000 файлов, которые изменила сборочная машина. Таким образом, мы выполняли "целевые" слияния, иногда по файлу за раз. Особенно с файлами.dpr или.bdsproj, которые имеют законные изменения (например, включение дополнительного модуля). Теперь я знаю, что происходит, поэтому я могу положить конец безумию.
Спасибо, переполнение стека!
Мы рекурсивно удалили его в нашем проекте, потому что почти все файлы содержали эту информацию, что делало слияние очень раздражающим (если был изменен только один файл, все файлы должны были быть объединены). Отныне мы будем сливаться только с корнем, что должно избежать этой ситуации в будущем.
До сих пор это не доставляло нам никаких проблем. Ведение журнала по-прежнему доступно для файлов и, кажется, то же самое (но все равно на свой страх и риск!).
О, мы сделали это на нашем стволе, прямо перед тем, как сделать новую ветку. Таким образом, мы можем начать с чистого листа.
У нас также была эта проблема в моей команде, и это сделало весь процесс слияния немного запутанным. Прочитав это, я попытался удалить свойство svn:mergeinfo из ряда файлов, и после некоторого дальнейшего тестирования похоже, что это решило проблему.