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


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

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

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

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

10 67

10 ответов:

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

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

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

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

SVN 1.7 и позже

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

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

SVN до 1.7

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

чтобы избежать этого, только слейте в" корневую " папку ветви, например "/филиалы / обслуживание 2.икс." Ни один из файлов или папок ниже "/филиалы / обслуживание 2.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, просто верните ее и снова выполните слияние, проверив родословную ignore.

Enter image description here

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

Я бы добавил, что, по крайней мере, одна часть эта ошибка была исправлена в 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 свойства.

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

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

Это не дало нам никаких проблем до сих пор. Регистрация по-прежнему доступна в файлах и, похоже, такая же (но все равно делайте это на свой страх и риск!).

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

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

большой вопрос, и ответ! В последнее время у нас возникла эта проблема, потому что мы пытаемся обойти ограничения нашей автоматизированной системы сборки. Наша система сборки автоматически увеличивает .и некоторые из них тоже .ДПР./файлы dpk с информацией о версии и пути.

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

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