Обнаружение реинтеграции или слияния веток в сценарии предварительной фиксации

Question

В сценарии предварительной фиксации возможно (и если да, то как) определить коммиты, вытекающие из svn merge?

svnlook changed ... показывает файлы, которые изменились, но не различает слияния и ручные изменения.

В идеале я также хотел бы различать стандарт merge и merge --reintegrate,

Фон:

Я изучаю возможность использования хуков предварительной фиксации для реализации политик использования SVN для нашего проекта.

Одна из политик гласит, что некоторые каталоги (такие как /trunk) не следует изменять напрямую, а изменять только путем реинтеграции ветвей функций. Поэтому сценарий предварительной фиксации отклоняет все изменения, внесенные в эти каталоги, кроме реинтеграций ветвей.

Есть идеи?

---

Обновить:

Я исследовал svnlook команда, и самое близкое, что у меня есть, это обнаружить и проанализировать изменения в svn:mergeinfo свойство каталога. Этот подход имеет некоторый недостаток:

1. svnlook может пометить изменение свойств, но не то, какое свойство было изменено. (разница с proplist предыдущей ревизии не требуется)
2. Осматривая изменения в svn:mergeinfo, можно обнаружить, что svn merge был запущен. Однако нет способа определить, являются ли коммиты просто результатом слияния. Изменения, сделанные вручную после слияния, останутся незамеченными. (связанный пост: Различить дерево транзакций по другому пути / ревизии)

Answer 1

В конце концов я прибег к неидеальному решению, то есть обнаружению изменений в svn:mergeinfo свойство в верхнем каталоге дерева изменений (реализовано в SVNTransaction.is_merge_operation()).

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

Он также не может различить merge и merge --reintegrate,

Другие ограничения включают в себя зависимость от svn:mergeinfo который модифицируется пользователем и не используется в более старой версии Subversion.

Рассматриваемые сценарии фиксации предназначены для мягкого напоминания о фиксации коммитов, которые идут вразрез с руководящими принципами проекта, а не с механизмом контроля доступа, поэтому перечисленные выше ограничения не являются ограничителем показа. Тем не менее, я все еще в поисках улучшений. Комментарии и дальнейшие предложения приветствуются.

Answer 2

К сожалению, Subversion не обеспечивает фиксацию только слиянием

если у меня есть доступ к ветке, я могу сделать все, что угодно после слияния и перед коммитом

также слияние Subversion происходит на стороне клиента

Многие инструменты хранилища кода будут сливаться на сервере. т.е. обеспечить, что вы перемещаете патчи только из одного потока в другой