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

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 не применяет коммиты только для слияния

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

также слияние подрывных операций происходит на стороне клиента

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