Comments 24
Да, правда
www.reviewboard.org/docs/manual/dev/users/tools/post-review/
post-review is a command line tool for Windows, Linux and MacOS X that simplifies both creating and updating review requests.
Если Вы о том, что это не минус — то смотря для кого как, естественно. Для нас — минус, т.к. у нас большинство пользователей сидит на TortoiseHg
Официальная тулза имеет явный плюс — она поддерживается разработчиками Review Board, при этом ее главный плюс — она не имеет GUI.

Fixed.
Очень все странно. Прежде всего — зачем ревьюить каждый коммит? Не проще ли было ревьюить все изменения из feature branch перед мерджем в mainline?
Процесс разработки построен таким образом, что фичи разбиваются на минимально возможные части, каждая из которых является оконченным функционалом, готовым для использования. Для каждой части создается тикет в JIRA. Каждый коммит содержит код такой части, поэтому есть смысл ревьювить каждый коммит.
В подавляющем большинстве случаев — да. Иногда для фич открываются свои ветки, но опять же — каждый коммит в такой ветке соответствует определенному оконченному функционалу, поэтому есть смысл его ревьювить.
Понял.

Вы с GitHub/BitBucket и их Pull/Merge Request'ами работали? Если да, то было бы интересно услышать сравнение оных с работой в RB. Я к тому спрашиваю, что ревью отдельных коммитов все же кажется мне несколько неоптимальным.
С Pull Request пока работал всего один раз (на GitHub) — сделал и получил ответ, что он принят. Так что по этому поводу ничего сказать не могу.

RB, кстати, позволяет постить ревью сразу для диапазона коммитов. В нашем случае в этом нет особой потребности. Хотя, если фичи действительно большие и на подфичи не разбиваются, то я согласен — ревьювить каждый коммит было бы неоптимально, а для каждой фичилучше было бы создавать отдельную ветку.
Ага, понял.
Невнимательно прочитал man. Перечитал еще раз, каждые 5 минут, это будет вот так:
*/5 * * * *
То, что Вы написали — это каждую 5-ю минуту часа.
Но вариант
0,5,10,15,20,25,30,35,40,45,50,55 * * * *
тоже вполне рабочий, хотя и записан неоптимально.
Мне прям захотелось попросить Вас привести пример добавления скрипта на выполнение каждую минуту :)
Неслабые такие требования у системки… Т.е. я понимаю когда требуется много памяти под большую нагрузку. Но что бы даже не запускалось при двух гигах…

Интересно на чём оно такое написано.
Прочитайте внимательней, под 2 GB запускалась, но
при просмотре diff-ов то и дело вылетала ошибка «Can not allocate memory».
А написана RB на Python.
Ну так это равносильно просто запуску — не было же орды запросов на сервер.

Вообще они там явно что-то накосячили. Достаточно взглянуть сколько занимает ресурсов тот же самый diff в самом mercurial.

А написана RB на Python.

Хм, я сам люблю серверные вещи на Питоне по быстрому делать. Он конечно не самый шустрый, но таких диких результатов что-то не припомню. Или взять тот же Django — весьма жирный фреймворк, а на 2 гигах вполне себе летать будет, если не орды пользователей.
У нас работает на виртуалочке с 2GB и ни разу не жаловалась на «Can not allocate memory». Ревью буквально вчера постили на 276 файлов, скушала и не подавилась. Правда у нас версия 1.6.3, может они в 1.7.* чего-то накрутили требовательного к памяти, не знаю.
Специально сейчас пошел полистал ревью это огромное и параллельно смотрел хтопом сколько памяти откушано. Выше 420 MB не поднимается. Что само по себе странно, ибо у нас под memcached отдан 1GB.
Если я правильно понял у вас ревью постится с сервера автоматизированно, люди в этом участия не принимают. Зачем тогда вы мучались с плагином под thg, на сервере то можно без проблем и post-review использовать в пост-коммит хуке.
Тут сыграло роль то, что мы до этого уже пользовали плагин и с ним разобрались. А так, да, можно было и post-review использовать.
Only those users with full accounts are able to leave comments. Log in, please.