Поделиться общими / полезными хуками предварительной фиксации SVN

У нас есть ловушка фиксации сообщения, которая отправляет сообщение в аккаунт Twitter. Использует twitsvn (отказ от ответственности: я участник этого проекта).

Глупый? Может быть ... но это оказалось для нас хорошим способом сообщить о том, что происходит в нашем репозитории, некоторым членам нашей команды, испытывающей трудности с контролем версий. Как только SVN начал разговаривать с ними через свой твиттер-клиент, он уже не был похож на черный ящик.

Что пользователь фактически ввел комментарий к сообщению о фиксации, и что оно содержит конкретный номер проблемы, которую нужно отслеживать.

Проверка абсолютных путей в различных текстовых файлах (например, VRML, XML и т. Д.). У большей части зарегистрированного кода никогда не должно быть абсолютных путей, однако некоторые люди и инструменты настаивают на создании жестко запрограммированного кода.

Я подсчитываю количество слов при отправке сообщений. Они должны состоять из 5 или более слов. Это привело к некоторым комедийным оскорблениям в мой адрес ...

• Проверьте наличие вкладок и отклоните регистрацию.
• Проверьте наличие несовместимых окончаний строк и отклоните регистрацию.
• Проверьте наличие «CR: [имя пользователя]» и отклоните регистрацию, если нет проверки кода.

Возможно, вам стоит взглянуть на: http://svn.apache.org/repos/asf/subversion/branches/1.6.x/www/tools_contrib.html#hook_scripts (эта страница может быть устаревшей, очевидно, она больше не поддерживается для Subversion 1.7)

Или прямо по адресу: https://svn.apache.org/repos/asf/subversion/trunk/contrib/

Мне нравится использовать svn хуки, чтобы:

• обеспечить соблюдение более строгих требований стиля кода
• проверьте очевидные синтаксические ошибки
• убедитесь, что специальные ключевые слова Trac, такие как "Исправления" или "Адреса", действительно предшествуют соответствующему номеру проблемы.

Я проверяю тип файла и убеждаюсь, что некоторые запрещенные типы не зафиксированы случайно (например, .obj, .pdb). Ну, не с тех пор, как в первый раз кто-то проверил 2 гига временных файлов, сгенерированных компилятором :(

для окон:

@echo off

svnlook log -t "%2" "%1" | c:\tools\grep -c "[a-zA-z0-9]" > nul
if %ERRORLEVEL% NEQ 1 goto DISALLOWED

echo Please enter a check-in comment 1>&2
exit 1


:DISALLOWED
svnlook changed -t %2 %1 > c:\temp\pre-commit.txt

findstr /G:"%1\hooks\ignore-matches.txt"  c:\temp\pre-commit.txt > c:\temp\precommit-bad.txt
if %ERRORLEVEL% NEQ 0 exit /b 0

echo disallowed file extension >> c:\temp\precommit-bad.txt
type c:\temp\precommit-bad.txt 1>&2
exit 1

Я использую обработчик post-commit, чтобы переписать свойство author на понятное имя из нашего дерева ldap. (аутентификация с идентификатором сотрудника)

Отличный прием фиксации, который у нас есть в нашем архиве, - это проверка всех проектов Visual Studio .VCPROJ (или .CSPROJ), чтобы убедиться, что выходные каталоги не были изменены на что-либо локальное (обычно используется для отладки).

Эти проблемы будут правильно скомпилированы, но сборка все равно будет нарушена из-за отсутствия исполняемых файлов.

В компании, над которой я сейчас работаю, это проверено:

• Если для двоичных файлов установлен атрибут блокировки необходимости;
• Если файлы Java имеют стандартное уведомление об авторских правах и включает ли он текущий год;
• Если код правильно отформатирован (мы используем Jalopy для форматирования кода) - это может показаться глупым, но на самом деле это упрощает сравнение текста между разными версиями;
• Если в коде есть сообщение о фиксации;
• Если структура каталогов соответствует определенному (все проекты должны находиться в определенной папке SVN, и каждый проект должен иметь теги, ветвь и главную папку);

Я думаю, это все.

Мне нравится идея проверки, связана ли фиксация с заявкой; для меня это действительно имеет большой смысл.

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

Я использую check-mime-type .pl pre-commit hook, чтобы проверить, установлены ли параметры MIME Type и End of line для зафиксированных файлов. Я использую Subversion для публикации файлов, которые будут отображаться на веб-сайте с помощью DAV, и все файлы без установленного типа MIME обслуживаются как текстовые файлы (например, исходный HTML-код отображается в браузере вместо визуализированной разметки).

Вставьте примечание в багтрекер Mantis с подробностями списка изменений на основе сообщения фиксации, имеющего "номер проблемы" или тому подобное, через RegEx.

Что у него есть сообщение о фиксации, и это! = Чем «исправление ошибок». Блин, я ненавидел эти бесполезные сообщения!

Мы используем комбинацию ловушек перед фиксацией и после фиксации, чтобы автоматически обновлять bugzilla с помощью связанной записи из фиксации svn.

Мы используем вторую ловушку (перед фиксацией), чтобы гарантировать, что соответствующие свойства svn: eol-style и svn: keywords установлены для файла перед его добавлением в репозиторий.

У нас есть третий (post-commit) хук, который запускает сборку и отправляет результаты по почте, если сборка не работает, а также чтобы проинформировать всех, когда сборка будет снова исправлена.

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

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

Для интеграции с bugzilla я бы посоветовал посмотреть scmbug.

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

#!/bin/bash

REPOS="$1"
TXN="$2"

# Exit on all errors.
set -e
SVNLOOK=svnlook
echo "`$SVNLOOK changed -t "$TXN" "$REPOS"`" | while read REPOS_PATH
do
  if [[ $REPOS_PATH =~ A[[:blank:]]{3}(.*)\.(sh|c|h|cpp) ]]
  then
    if [ ${#BASH_REMATCH[*]} -ge 2 ]
        then
    FILENAME=${BASH_REMATCH[1]}.${BASH_REMATCH[2]};

    # Make sure shell scripts are executable
    if [[ sh == ${BASH_REMATCH[2]} ]]
    then
        EX_VALUE="true"
            if [ -z "`$SVNLOOK propget -t \"$TXN\" \"$REPOS\" svn:executable \"$FILENAME\" 2> /dev/null`" ]
            then
            ERROR=1;
                echo "svn ps svn:executable $EX_VALUE \"$FILENAME\"" >&2
        fi
        EOL_STYLE="LF"
    else
        EOL_STYLE="native"
    fi

    # Make sure every file has the right svn:eol-style property set
        if [ $EOL_STYLE != "`$SVNLOOK propget -t \"$TXN\" \"$REPOS\" svn:eol-style \"$FILENAME\" 2> /dev/null`" ]
        then
        ERROR=1;
            echo "svn ps svn:eol-style $EOL_STYLE \"$FILENAME\"" >&2
    fi
    fi
  fi
  test -z $ERROR || (echo "Please execute above commands to correct svn property settings." >& 2; exit 1)
done

Как насчет ловушки для компиляции проекта? например Беги сделай все. Это гарантирует, что никто не проверит код, который не компилируется! :)

Решение проблемы отсутствия внешних файлов в SVN 1.5 с помощью PostUpdate и PreCommit

Мне бы понравился хук, который проверяет заметку [Reviewer: xyz] в сообщении фиксации и отклоняет фиксацию.

Я думаю о написании одного, чтобы проверить doctype в файлах aspx / html, просто чтобы убедиться, что все используют правильный.

Кроме того, у вас может быть обработчик до (или после) фиксации, отправляющий уведомление на ваш CI-сервер как описано в блоге Hudson

Я проверяю коллизию регистров (тупые окна), а также require-mergeinfo.pl, чтобы убедиться, что клиент не менее 1,5 - таким образом svn: mergeinfo всегда будет установлен