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

Можно ли в сценарии предварительной фиксации (и если да, то как) идентифицировать фиксации, происходящие из svn merge?

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

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

Задний план:

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

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

Любые идеи?

Обновлять:

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

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

svn pre-commit-hook svn-merge svnlook svn-merge-reintegrate
person Shawn Chin    schedule 09.01.2012    source источник
comment
Вам нужно различать реинтеграцию и регулярные слияния?   -  person Álvaro González    schedule 09.01.2012
comment
@ ÁlvaroG.Vicario В идеале, да. Но я бы удовлетворился простым обнаружением слияний любого рода.   -  person Shawn Chin    schedule 09.01.2012
comment
Я не думаю, что синтаксический анализ svn:mergeinfo хрупок: это свойство является механизмом, используемым Subversion для отслеживания изменений. Однако я не уверен, что опция --reintegration имеет какое-либо прямое влияние на свойства ревизии. Извините, я ничем не могу больше помочь.   -  person Álvaro González    schedule 09.01.2012
comment
@ ÁlvaroG.Vicario хорошее замечание. Я разберусь в этом подробнее.   -  person Shawn Chin    schedule 09.01.2012
comment
К сожалению, одного взгляда на svn:mergeinfo недостаточно. См. обновления выше.   -  person Shawn Chin    schedule 11.01.2012
comment
Вы используете клиент / сервер SVN 1.6 или 1.7? В версии 1.7 слияние выполняется несколько иначе, и, возможно, с ним легче справиться. Мне любопытен тот же вопрос, но большая проблема с 1.6 заключается в том, что людей настолько раздражает ложное коммитирование свойства mergeinfo, что они (или я!) Удаляют mergeinfo. И наоборот, коммиттеры могут непреднамеренно зафиксировать измененную информацию mergeinfo в рабочих проектах 1.6 и были бы в ужасе, если бы я отозвал фиксацию обратно. Так что, может быть, важна ваша процедура? Я хотел бы услышать то, что, по вашему мнению, работает лучше всего.   -  person AnneTheAgile    schedule 29.01.2012

Ответы (2)


arrow_upward
2
arrow_downward

к сожалению, Subversion не обеспечивает принудительное слияние, только коммиты

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

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

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

person Kalpesh Soni    schedule 04.05.2012

arrow_upward
2
arrow_downward

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

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

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

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

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

person Shawn Chin    schedule 14.12.2012