Обнаружение реинтеграции веток или объединение в pre-commit script

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

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

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

Справочная информация:

Я изучаю возможность использования привязок pre-commit для обеспечения соблюдения политик использования SVN для нашего проекта.

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

Любые идеи?

Обновление:

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

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

Ответы

Ответ 1

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

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

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

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

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

Ответ 2

К сожалению, subversion не применяет слияние только commits

Если у меня есть доступ к ветке, я могу делать все после слияния и до фиксации

также слияние субверсии происходит на стороне клиента

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