Определение базовой ревизии транзакции в pre-commit

Question

Я пишу ловушку перед фиксацией, где я хотел бы применить какое-то правило, основанное на содержимом файла перед транзакцией. Поэтому, когда транзакция начинается, я бы хотел, чтобы svnlook cat содержал содержимое любого файла с пометкой "U", "UU" или "D" без ожидающих изменений. Безопасно ли для меня взять предоставленный идентификатор транзакции (второй аргумент для предварительной фиксации), убрать тире и любые символы, следующие за ним, и считать, что это "базовая ревизия"? Есть ли лучший способ получить эту информацию?

Answer 1

Прямой ответ - нет. Номер транзакции может быть любым. Тем не мение, svnlook youngest <repos> вернет последнюю ревизию, которая должна быть именно тем, что вы ищете.

Будьте осторожны с хуками предварительной фиксации:

• Убедитесь, что вы не делаете то, что займет много времени. Разработчики должны ждать завершения предварительной фиксации, и если вы потратите 7-10 секунд на обработку чего-либо, разработчики будут очень разочарованы.
• Вы не можете (и не должны) изменять передаваемые данные. Если он соответствует тому, что вы хотите, разрешите коммит. Если это не так, не разрешайте коммит.
• Убедитесь, что вы не собираетесь останавливать то, что может быть законной деятельностью. Например, некоторые сайты используют ловушки предварительной фиксации, чтобы не допустить внесения изменений кем-либо, если они не помещают заявку в сообщение фиксации, и это сообщение фиксации является заявкой, назначенной этому разработчику, и эта заявка находится в открытом состоянии. Можете ли вы представить себе веселье, которое возникает, когда разработчик не может зафиксировать изменение, потому что заявка назначена кому-то другому, и что единственный человек, который может изменить назначение, отключен на неделю?

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

Вероятность того, что разработчик, вероятно, поступит правильно, составляет 90%. Этот руководитель разработки, вероятно, уже знает об этой проблеме. И, если есть проблема, вы можете отменить изменение.

Answer 2

И добавьте 1 к младшему. например:

the_revision=$(svnlook youngest ${REPOS})
((the_revision++))

Answer 3

Базовая ревизия не определена, пока ревизия не будет принята. Если другое изменение не изменяет те же узлы, оно может быть зафиксировано во время обработки. Только последняя часть коммита является эксклюзивной.