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

Каковы некоторые общие и/или полезные крючки для фиксации для SVN?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

Проверить вкладки и отклонить регистрироваться.
Проверить наличие непоследовательной строки окончания и отклонить регистрацию.
Проверить наличие CR: [имя пользователя] "и отклонить регистрацию если проверка кода отсутствует.

Ответ 6

Вы можете взглянуть на: 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/

Ответ 7

Мне нравится использовать svn hooks для:

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

Ответ 8

Я проверяю тип файла и удостоверяюсь, что некоторые запрещенные типы не были совершены случайно (например .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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

Я предполагаю, что это.

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

Мы используем комманду pre-commit и post-commit hook для автоматического обновления bugzilla с соответствующей записью из svn commit.

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

У нас есть третий (пост-фиксативный) крюк, чтобы начать сборку и отправить результаты, если сборка нарушена, и сообщить всем, когда сборка была исправлена снова.

У нас есть четвертый (post-commit) крюк, чтобы начать репликацию svn, чтобы убедиться, что репликация offsite максимально актуальна.

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

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

Ответ 17

Я использую следующий hook script, чтобы убедиться, что окончательные строки исходного кода и разрешения сценариев оболочки верны (это неприятно, когда кто-то проверяет окна, когда все выглядит нормально и разбивает сборку 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

Ответ 18

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

Ответ 19

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

Ответ 20

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

Ответ 21

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

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

Ответ 22

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