Как реализовать SVN-хук с максимальной эффективностью?

Question

У нас есть следующие инструменты:

• Subversion (версия 1.5.9)
• Polarion (версия 3.2.2)

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

Итак, какова лучшая стратегия для обеспечения ловушек перед фиксацией, которые будут

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

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

Answer 1

Недавно я использовал Python для реализации хука post-commit , который сканирует разные проекты в одном и том же хранилище и затем действует соответствующим образом. Я новичок в Python, поэтому в следующем скрипте могут быть некоторые недостатки (или даже прямые ошибки), но он работает для наших целей:

#!/usr/bin/env python

import commands
from subprocess import *
import os
import sys

# This is a post-commit hook.  The arguments passed to the hook
# are different than a pre-commit hook, and the syntax/use for
# svnlook will probably be different too.

def check_repo_and_do_stuff(repos, rev):

    dirs_changed_cmd =
    p1 = Popen('%s dirs-changed %s -r %s' % (SVNLOOK, repos, rev)
    dirs_changed = p1.communicate[0]

    for line in dirs_changed:

        if line.find('/part-of-path-for/project1') >= 0:
            do_stuff_for_project1()

        if line.find('/part-of-path-for/project2') >= 0:
            do_stuff_for_project2()

def do_stuff_for_project1()...

def do_stuff_for_project2()...

SVNLOOK='/usr/bin/svnlook'

# Take the arguments that svnserve passes on the command-line
repos = sys.argv[1]
rev = sys.argv[2]

check_repo_and_do_stuff(repos, rev)

Надеюсь, это поможет.

-Zachary

Answer 2

Если Java замедляет работу, но Java используется только в небольшом проценте времени, я бы написал что-то более легкое. то есть в Windows используйте файл .bat. Затем для проектов (или файлов или пользователей), которым это требуется, вызовите более дорогой хук Java из легкого хука. Таким образом, вы замедляете коммит только тогда, когда это необходимо.

Answer 3

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

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

Answer 4

Хук-скрипты на основе Java работают медленно и влияют на время отклика Subversion в целом, особенно если вы работаете на сильно загруженных серверах. Наилучшие результаты будут достигнуты при внедрении аудитов и метрик для повышения качества. Отслеживая прослеживаемость в аудитах, команда проекта может следить за его прогрессом, получая лучшие и лучшие уровни.

Answer 5

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

В дополнение к лучшей производительности, это даст вам детальный контроль над вашими репозиториями, позволяя вам иметь отдельный контроль доступа, отдельные хуки для репо (проекта) и т. Д.