SVN hooks: изменение комментария к ревизии

[xinn]

А у Вас в названии топика опечатка =)

[easterism]

Чорт. Спасибо. Текст вроде прочел, а о главном зыбыл :)

[pro100tak]

А зачем менять комментарий к коммиту?

[m_a_d]

Самое распространенное — нечаянно ткнул «commit», не дописав комментарий.

[pro100tak]

Дык не в хуке же? Для таких случаев в пре-коммите просто проверяем svn:log и если чего не так — заворачиваем обратно :)

[m_a_d]

Дык что значит «если чего не так»? Если комментарий пустой — то это можно отследить. Но если половину комментария написал, а вторую не успел и ткнул «коммит» — тут как быть?

[pro100tak]

Сорри, вот ответ — habrahabr.ru/blogs/development_tools/114273/#comment_3694396

[pro100tak]

Если чего не так:
1. Лог пустой;
2. Неправильное форматирование;
2.1. Нет номера тикета вначале лога;
2.2. Присутствуют символы, отличные от английского алфавита, цифр и т.д.;
3. Придумать самим.

У нас, например, для интеграции с TRAC вначале лога должен быть номер issue (не знаю как точно перевести). Плюс у каждой команды/проекта/организации может быть соглашение об именовании для логов в коммитах.

Также, я пока совсем не понимаю — НА ЧТО изменит комментарий бездушная машина :) Для меня алгоритм работы с «плохим» комментарием, который нужно изменить: просто не провести коммит. А автору коммита уже какбе должно быть понятно — на что менять и т.д. :)

[easterism]

Внесу ясность. Я взял для примера изменение коммента именно потому, что этот функционал (пунк меню) есть во всех клиентах (по крайней мере для SVN). Также можно менять например автора (вот тут я и сам не знаю нафига это надо)

[easterism]

[m_a_d]

НА ЧТО изменит комментарий бездушная машина

Так изменяет-то автор комментария, а не бездушная машина сама по себе! Например, через меню, которое привели в комментарии ниже.

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

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

[Deimus]

Статья отличная, поможет в следующих(и не только ситуациях):
1. Если автор коммита «случайно» использовал мат(можно просто удалить ее);
2. Если коммит по сути нормальный, но не соответствует принятым «стандартам» компании(например, нужно объязательно указать автора коммита и ревьюера(тот, кто проверял изменение до коммита автора));
3. Если комментарий не полноценный, типа «Подправил соответствующие исходники» и т.п.
(список может продолжаться:)

[zvirusz]

При создании репозитория в папку hooks кладутся примеры хуков. В том числе — pre-revprop-change.tmpl — для изменения сообщения лога. Его нужно лишь переименовать и сделать исполняемым.

[scorcher]

я, когда настраивал связку SVN с redmine, столкнулся с тем, что redmine подтягивает к себе все ревизии и логи. При изменении коммента в частности по причине «перепутан номер тикета» приходилось чистить все таблицы, связанные с хранилищем и запускать скрипт, который подтягивал изменения, т.к. этот скрипт подтягивает изменения только начиная с последней ревизии, которая лежит в redmine.
С ростом репозитория выросло и кол-во ревизий, которые надо было перелопатить из SVN в mysql :)
это стало тоскливо и пришлось немного подшаманить хук, так чтобы он вычищал только те ревизии из redmine, которые моложе той, у которой изменили лог.

скрипт выглядит так (может кому-то будет полезно):
post-revprop-change

#!/bin/sh

REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

# Generate SELECT statement to fetch last changements
SEL="SELECT id FROM redmine.changesets WHERE revision >= $REV"

echo "Truncate changesets tables into redmine..."
echo "DELETE FROM redmine.changes WHERE changeset_id IN ($SEL);" \
| mysql -u redmine --password="-----------------"
echo "DELETE FROM redmine.changesets_issues WHERE changeset_id IN ($SEL);" \
| mysql -u redmine --password="-----------------"
echo "DELETE FROM redmine.changesets WHERE revision >= $REV;" \
| mysql -u redmine --password="-----------------"
echo "Fetching changesets from SVN to redmine..."
rake -f PATH_TO_redmine/current/Rakefile redmine:fetch_changesets RAILS_ENV=production
exit 0

pre-revprop-change — поставил ограничение, чтобы только определенный автор мог менять лог

#!/bin/sh

REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

if [ "$USER" = "didenko" -a "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then
        exit 0
fi

echo "Changing revision properties is prohibited. Please ask Administrator about it." >&2
exit 1

ну а post-commit стандартный почти как советует автор

#!/bin/sh

REPOS="$1"
REV="$2"

wget  --dns-timeout=3 --connect-timeout=3 -q \
"http://redmine.dev.rugion.ru/sys/fetch_changesets?key=---" \
 >/dev/null 2>&1 &

exit 0

[chemodax]

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

Более того при редактировании хуков через интерфейс VisualSVN Server хук будет сохранен в виде стандартного батника. Единственное что насколько я помню VisualSVN Server по умолчанию сохраняет хуки с расширением .cmd, но при этом читает .cmd и .bat.

[easterism]

Дело в том, что я сначала пытался запустить батник в VisualSVN, но он вупор не хотел этого делать. Причины не знаю, батник лежал в /hooks?

Впрочем, возможно это потому, что сам хук в менеджере не был активен.

[chemodax]

VisualSVN Server Manager ничего не изобретает, он просто смотрит в стандартную папку hooks если там есть файл с расширением .cmd или .bat он его показывает и редактирует.

Каким образом Вы пытались запустить батник в VisualSVN?

[easterism]

Я лишь имел ввиду, что VisualSVN Server Manager никак не отреагировал на батник в папке hooks. Верю, что вы правы, т.к. я сам с VisualSVN сервером сильно не работал.
В топик добавил ваше наблюдение.

[davinchi]

Для Mercurial:
$ hg commit -m 'inccorrect log message'
$ hg rollback
$ hg commit -m 'correct log message'

А вот если вы успели сделать push в основной репо — всё будет куда печальнее, чем для Subversion: придётся убалтывать змея-горыныча с тремя головами :-/