вторник, 8 февраля 2011 г.

Триггеры perforce

Наша разработка ведется очень демократично. Мы пишем под FreeBSD (исторически и лицензионно сложилось), используем кодировку koi8-r (тоже исторически сложилось, FreeBSD не очень то дружит с UTF-8 и по сей день).

Но в то же время мы не навязываем разработчикам никаких условий... Каждый работает так, как ему комфортнее. Жить под FreeBSD - я не пожелаю и врагу (ну вы уже знаете, как я ее не люблю :) ). Наши разработчики пользуются своими любимыми редакторами, сидят в своих любимых системах с разными локалями и интерпретациями концов строк.

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

В perforce используются типы файлов, с помощью которых можно задавать отчасти кодировку, расстановку тегов и формат файлов. Тип unicode, в частности, позволяет каждому клиенту предоставлять текст в той кодировке, которую тот использует. Что крайне неудобно, если хочется везде иметь koi8-r.

Поэтому список типов файлов волевым решением был жестко ограничен следующими типами: binary, text, symlink. Для воплощения этого в perforce используются триггеры.
#!/bin/sh
REV=$1
lsfiles()
{
p4 files //depot/...@=$1 | grep -v '(binary' | \
grep -v '(text' | grep -v '(symlink' | \
grep -v 'delete change'
}

if [ `lsfiles $REV | wc -l` != 0 ]; then
echo "Using forbidden filetypes"
lsfiles $REV
exit 1
fi
Надо сказать что действия с репозиторием в триггере ограничены. Например доступ к ревизии осуществляется исключительно по номеру @=<номер ревизии>, ибо это pending changelist.

Указанный выше фильтр допускает применение модификаторов, как-то text+k, text+ko, text+kox, но и тут собака порылась... В мануале написано:
The following type aliases exist for backwards compatibility:
xtext text +x
То есть ты, зараза такая должна отображать их по новому!!! а ты, зараза такая, вместо этого, при указании text+x радостно пишешь - xtext... Пришлось добавить дополнительный grep на этот случай.
grep -v 'text)'
Теперь осталось включить триггер..
$ p4 triggers
Triggers:
forbidden change-content //depot/... "prohibited-file-types %change%"
После чего ни один коммит содержащий unicode, UTF16 или еще какую непонятную фигню не пройдет.

В этом триггере возможно использование change-submit, для указанной ревизии список файлов должен быть уже на сервере. Но я как-то в процессе экспериментов остановился на change-content, пусть пока так стоит.

Правда это не спасает нас от того, что в тексте файла буквы могут быть любые. Для этого нужна еще одна проверка на тело файлов. В частности UTF-8 часто проскакивает. Надо только придумать как лучше всего проверить файл на предмет некорректной кодировки.

Наверное подойдет что-то типа того:
iconv -f utf-8 -t koi8-r && die

11 коммент.:

Aquary комментирует...

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

А сколько народу вообще работает над проектом? Как часто призодится работать над кодом, изменённым другим разработчиком? Есть ли стандарт кодирования? Используются ли инспекции кода (code reviews)?

Андрей Валяев комментирует...

Народу у нас не очень много, на данный момент 4 программиста.

Стандарт кодирования у нас тоже есть, кратенький. :)

При большей команде наверное нужно больше строгостей.

Aquary комментирует...

Может проще застроить остальных трёх, чтобы писали нормальный код, чем извращаться с триггерами, которые всё равно каких-то ситуаций не ловят? :)

Ну просто тут, по-моему, типичный случай, когда тулза помогает лишь отчасти и проблема решается элементарной самодисциплиной :)

Опять же, давно пора бы уже перейти на Юникод, тем самым решив пробелмы с кодировкой... ИМХО, конечно.

Aquary комментирует...

Кстати, ещё интересно - почему выбрали Перфорс, особенно для такой небольшой команды? Понимаю - мощный, богатый на фичи... но ведь платный, насколько помню?

Андрей Валяев комментирует...

Автоматические проверки значительно лучше чем кодревью.

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

Лучше всего весь непререкаемый стиль кодирования надо контролировать автоматически. Тем самым заставить всех писать правильный код. :)

FreeBSD по моему до сих пор не особо дружит с UTF-8. Она у нас в качестве платформы.

Perforce бесплатный. Наша компания перешла на него где-то в 2003 или в 2004, с SourceSafe. Я так полагаю что svn тогда еще не появился, не говоря уж про всякие git, mercurial. а по сравнению с cvs - Perforce безусловно рулит. А теперь уже так просто не перейдешь... база кода, всякое такое. :)

Aquary комментирует...

Конечно, инструментальная поддержка - отличная вещь. Но она должна дополнять, автоматизировать, но никак не провоцировать програмера на работу спустя рукава.

Бесплатный Перфорс - на каких условиях? Для мелких команд? Просто мне подводилось знакомиться с ним в составе большой команды - там было платно :)

А то, что мощнее - это даже не вопрос :) Мощнее - только ClearCase ;)

Андрей Валяев комментирует...

Конечно, инструментальная поддержка - отличная вещь. Но она должна дополнять, автоматизировать, но никак не провоцировать програмера на работу спустя рукава.

Как он сможет работать спустя рукава, если ему не дадут закоммитить код с нарушениями?

Естественно это не отменяет кодверью. :)

Про перфорс - интересный вопрос... надо надо уточнить на каких условиях мы его используем. :)

Aquary комментирует...

> Как он сможет работать спустя рукава, если ему не дадут закоммитить код с нарушениями?

Работать спустя рукава и уже после автоматом править ошибки - это разные стадии :)
Конечно, автоматика исправит ряд ошибок, однако, по-моему, лучше всё-таки искоренить источник зла, чем ежечасно с ним бороться ;) Собственно, кодревью для того и проводят :)

А про лицензирование Перфорс - и вправду интересно.

Андрей Валяев комментирует...

Работать спустя рукава и уже после автоматом править ошибки - это разные стадии :)
Конечно, автоматика исправит ряд ошибок, однако, по-моему, лучше всё-таки искоренить источник зла, чем ежечасно с ним бороться ;) Собственно, кодревью для того и проводят :)


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

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

Вопрос кстати в том, на что собственно должен смотреть ревьюер. Он должен расстановку пробелов проверять? Или глобальные проблемы высматривать?

Есть практики ревью до коммита, Я пока не знаю как это сделать в перфорсе.

Aquary комментирует...

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

Если работа ведется сразу на "транке" - стало быть, надо делать не только pre-commit хуки, но и хитрую систему ревью по почте или ещё как, а потом ещё и верифицировать, что присланное было не только доработано, но и положено под контроль версий в том виде, в каком его хотели видеть инспекторы.

Андрей Валяев комментирует...

прекоммит хуки и делаю. :)

А ревью мы проводим постфактом. Если в процессе ревью обнаруживается что-то серьезное - исправление следует.

ветки делаем только для различных экспериментов.