ловушка post-receive не может обновить билет Trac при отправке несколькими коммитами для одного и того же билета

Question

Существует среда Trac 0.11.7, которая интегрируется с репозиторием Git с помощью GitPlugin .Этот репозиторий имеет хук пост-получения, который является копией копии, предоставленной командой GitPlugin.

Хук пост-получения запускается, когда разработчики отправляют свои изменения на сервер.Если пакет содержит один коммит на тикет, то все работает отлично - отдельные сообщения коммитов связаны с соответствующими тикетами.

Однако, если есть несколько коммитов для одного и того же тикета, то только тикет связывается только с последним коммитом, со следующей ошибкой для остальных коммитов:

Непредвиденная ошибка при обработке идентификатора заявки 1: столбец билета, время, поле не являются уникальными

Хук (записанов python), и может показаться, что временная часть аргумента now вызова ticket.save_changes(eml, msg, now, db, cnum + 1) в функции handle_commit отличается только на миллисекунды для последовательно обрабатываемых коммитов.

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

Что было бы хорошим и простым решением для разрешения вышеуказанной ситуации?

Answer 1

Чтобы точно преодолеть это ограничение, вызванное автоматическим представлением, то есть BatchModifyPlugin , при котором также был изменен внутренний формат метки времени Trac за 0,12 с POSIX секунд до POSIX микросекунд (с 1970-01-01 0:00).

Так что лучшим решением будет обновление до Trac 0.12.3.Другой способ, предложенный 01es, - вместо этого возиться с плагином.Извините, но это всего лишь взлом для взлома, который не должен быть обвинен в проблеме.Даже минимального интервала между автоматическими фиксациями будет достаточно, чтобы ваша проблема исчезла, как только вы начнете развертывать текущую стабильную версию Trac.

Answer 2

Двумя наиболее очевидными решениями было бы либо перейти на альтернативную СУБД, поддерживаемую Trac (например, MySQL), либо искусственно добавить дополнительную секунду к отметке времени, если существует несколько коммитов для одного и того же билета.

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