Subversion помечает неизмененные файлы как измененные
Я использую это, чтобы получить список измененных файлов между двумя наборами изменений:
git diff --name-status <SHA1> <SHA2> | cut -f2
3 ответа
Когда файл / папка имеет явную информацию слияния (т.е. свойство svn: mergeinfo ), каждое последующее слияние с ветвью будет обновлять эту информацию слияния, даже если файл / папка не связаны. Это действительно раздражает, так как при каждом слиянии в список изменений вносится все больше и больше.
Чтобы избежать этого, выполняйте слияние только в «корневую» папку ветки, например, «/branches/main maintenance2.x». Ни один из файлов или папок ниже "/branches/main maintenance2.x" не должен получать mergeinfo. Следуйте совету по слиянию в svn book .
К сожалению, даже если вы выполняете слияние только в «корневой» папке ветки, пустые свойства svn: mergeinfo все еще могут отображаться в отдельные файлы и папки при их копировании, чтобы указать, что они не получили тех же слияний, что и их братья и сестры.
Если вы выполняете слияние только в корне, то, вероятно, будет безопасно удалить лишнюю информацию о слиянии поддерева. Один из способов сделать это - выполнить рекурсивное удаление свойства svn: mergeinfo для каждого файла и папки в корне вашего проекта.
Похоже, это было исправлено в SVN 1.7. Из примечаний к выпуску: Уменьшено количество изменений информации о слиянии поддерева .
It might be some kind of property change, possibly some automatic modification of the svn:mergeinfo attribute. You can tell if it's a property modification by running "svn stat". If the "M" is in the first column, it's changes in content, if it's in the second column, it's property changes.
The change is in the file properties. If you run svn proplist, you will see a lot of mergeinfo entries. This is because svn tracks merges in file properties. This is a new feature from 1.5, so it didn't occur in older versions.
I have never completely understood the exact reason why this happens, but it has to do with the internal implementation leaking through. Trying to understand it without understanding how svn is implemented is, as far as I have concluded, not possible. However, usually the root cause has to do with subtree merges. Eg. If you merge the changes of a subdirectory or a single file, rather than the entire branch/tag. In order to track what has been merged, subversion will put the mergeinfo property on the most general node, but apparently it's not intelligent enough in picking it. You can fix the problem by manually editing mergeinfo. Simply remove the property from all nodes below trunk, and make sure that trunk has all the merged revisions in its mergeinfo. Of course, this means that you have to make sure that the changes has actually been merged.
All in all rather confusing, but the good news is that the svn devs actually are working on making the whole thing more smooth.