Приветствую!
Возникла необходимость организовать очередь коммитов,
т.е. чтобы предовратить одновременный коммит несколькими пользователями.
процесс мне видится так: пользователи создают запросы на коммит.
cvs admin разрешает коммит пользователю, отправившему запрос первым.
если админ разрешил коммит определённому пользователю,
то он и только он может коммитить изменения до тех пор,
пока не будет удалён из очереди.

Подскажите, плиз,существуют ли готовые решения для cvs/svn, позволяющие реализовать вышеописанную процедуру?

Заранее спасибо за ответы.

Здравствуйте, stormgt, Вы писали:

S>Подскажите, плиз,существуют ли готовые решения для cvs/svn, позволяющие реализовать вышеописанную процедуру?
http://www.jetbrains.com/teamcity/delayed_commit.html ?

Здравствуйте, stormgt, Вы писали:

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

А можно в двух словах — зачем это?

Здравствуйте, rlabs, Вы писали:

S>>т.е. чтобы предовратить одновременный коммит несколькими пользователями.
R>А можно в двух словах — зачем это?
Для code review или тестов, скорее всего.

Здравствуйте, rlabs, Вы писали:

R>А можно в двух словах — зачем это?

Хочу решить две проблемы:
во-первых, обеспечить атомарность коммита.
Т.е. один человек коммитит багфикс.
после этого прогоняются тесты и строится билд.
если билд свалился или тесты не прошли, то очевидно, кто сломал всё

и вторая проблема. есть несколько junior developer'ов. и есть senior.
junior'ы могут коммитить тогда и только тогда, если senior разрешит.

Здравствуйте, Cyberax, Вы писали:

C>http://www.jetbrains.com/teamcity/delayed_commit.html ?

спасибо за линк. Их Pre-tested Commit — это одна из задач, которую мне нужно решить.

Здравствуйте, stormgt, Вы писали:

S>и вторая проблема. есть несколько junior developer'ов. и есть senior.
S>junior'ы могут коммитить тогда и только тогда, если senior разрешит.

А не проще научить junior'ов пользоваться branch'ами? И пусть senior даёт отмашку на merge.

Здравствуйте, stormgt, Вы писали:
R>>А можно в двух словах — зачем это?
S>Хочу решить две проблемы:
S>во-первых, обеспечить атомарность коммита.
S>Т.е. один человек коммитит багфикс.
S>после этого прогоняются тесты и строится билд.
S>если билд свалился или тесты не прошли, то очевидно, кто сломал всё:)
Это и так очевидно, глядя на список изменений и на их авторов.

S>и вторая проблема. есть несколько junior developer'ов. и есть senior.
S>junior'ы могут коммитить тогда и только тогда, если senior разрешит.
Идя таким путем, вы никогда не вырастите из джуниоров инженеров. Когда тебе не доверяют — ты не будешь ответственно относиться к своей работе.

Здравствуйте, stormgt, Вы писали:

S>Хочу решить две проблемы:
S>во-первых, обеспечить атомарность коммита.
Кстати, а вот для этого лучше использовать SVN или им подобные. Тем более, что в SVN1.5 наконец-то добавили merge tracking.

Здравствуйте, rlabs, Вы писали:

S>>junior'ы могут коммитить тогда и только тогда, если senior разрешит.
R>Идя таким путем, вы никогда не вырастите из джуниоров инженеров. Когда тебе не доверяют — ты не будешь ответственно относиться к своей работе.
Code review — это вполне нормальная практика. Более того, это ХОРОШАЯ практика, так как позволяет отлавливать многие ошибки junior'ов пока они ещё не попали в репозиторий.

Здравствуйте, Cyberax, Вы писали:

S>>>junior'ы могут коммитить тогда и только тогда, если senior разрешит.
R>>Идя таким путем, вы никогда не вырастите из джуниоров инженеров. Когда тебе не доверяют — ты не будешь ответственно относиться к своей работе.
C>Code review — это вполне нормальная практика. Более того, это ХОРОШАЯ практика, так как позволяет отлавливать многие ошибки junior'ов пока они ещё не попали в репозиторий.
В плане текущего момента — да. В плане личного роста — нет, ибо приучает к раздолбайству.
еще раз повторюсь (подробнее об этом где-то в Peopleware надо читать): нет доверия — нет ответственности.

Здравствуйте, rlabs, Вы писали:

C>>Code review — это вполне нормальная практика. Более того, это ХОРОШАЯ практика, так как позволяет отлавливать многие ошибки junior'ов пока они ещё не попали в репозиторий.
R>В плане текущего момента — да. В плане личного роста — нет, ибо приучает к раздолбайству.
Нет. С точностью "до наоборот". Если джуниор знает, что его код никто не будет смотреть, то он может временами подсовывать халтуру, на которую никто долго не наткнётся. Даже вполне неосознанно.

Зато когда он знает, что его код будут смотреть, а за халтуру настучат по ушам — то это весьма дисциплинирует.

R>еще раз повторюсь (подробнее об этом где-то в Peopleware надо читать): нет доверия — нет ответственности.
Ты доверишь курсанту в автошколе обучаться без инструктора?

Здравствуйте, Cyberax, Вы писали:

C>Code review — это вполне нормальная практика. Более того, это ХОРОШАЯ практика, так как позволяет отлавливать многие ошибки junior'ов пока они ещё не попали в репозиторий.

Я не вижу причин, почему нельзя делать code review не до, а после коммита.

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

Здравствуйте, Pzz, Вы писали:

C>>Code review — это вполне нормальная практика. Более того, это ХОРОШАЯ практика, так как позволяет отлавливать многие ошибки junior'ов пока они ещё не попали в репозиторий.
Pzz>Я не вижу причин, почему нельзя делать code review не до, а после коммита.
Работу остальных программистов в случае поломки не будет задерживать.

Pzz>Надо лишь требовать с юниоров (и не только с юниоров), чтобы коммиты не ломали билд и уже работающую функциональность. По крайней мере, не ломали совершенно очевидным образом, неочевидным кто угодно может сломать.
Часть неочевидностей как раз reviewer заметит.

Здравствуйте, Cyberax, Вы писали:

Pzz>>Я не вижу причин, почему нельзя делать code review не до, а после коммита.
C>Работу остальных программистов в случае поломки не будет задерживать.

Ну если коммит совсем плохой, можно и rollback сделать. Содержательно при этом ничего не теряется, все же есть уже в history сорс контрола.

C>Часть неочевидностей как раз reviewer заметит.

Желательно, однако, чтобы новый код попадал в оборот как можно раньше — это позволяет обнаружить находящиеся в нем ошибки (прошедшие сквозь rewiew или тесты при их наличии). А если review делается до коммита, это будет не так.

Здравствуйте, Pzz, Вы писали:

C>>Работу остальных программистов в случае поломки не будет задерживать.
Pzz>Ну если коммит совсем плохой, можно и rollback сделать. Содержательно при этом ничего не теряется, все же есть уже в history сорс контрола.
Угу, и тратим вместо нескольких минут времени одного reviewer'а по нескольку минут времени многих девелоперов.

C>>Часть неочевидностей как раз reviewer заметит.
Pzz>Желательно, однако, чтобы новый код попадал в оборот как можно раньше — это позволяет обнаружить находящиеся в нем ошибки (прошедшие сквозь rewiew или тесты при их наличии). А если review делается до коммита, это будет не так.
Почему? Новичок делает checkin, reviewer'ам приходит по почте оповещение, они смотрят через некоторое короткое время. Если что — сразу же по ушам бьют юниора.

Здравствуйте, stormgt, Вы писали:

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

Возможно, может показаться резкостью, однако не могу не удивиться тому, как народ пытается вернуться в каменный век... Почему — потому что эта задача давно известна в СМе (configuration management'е) и имеет опробованное годами решение — создание веток (бранчей, branches), как уже сказал в этой ветке Денис Хитрик.

Т.е. вместо того, чтобы уберегать юзера от коммита — его нужно поощрять к этому, но! коммит должен делаться не на HEAD (CVS) или trunk (SVN), а на отдельный бранч!

Вот здесь я привел краткое описание того, как обычно идет работа с бранчами в команде

Автор: Aquary
Дата: 22.08.07

Конечно, создание бранча — это лишняя пара команд, да и бранчи кто-то должен мержить вместе (СМщик или один из разработчиков) — однако лучшего решения тут нет.

Если есть вопросы по политике ведения бранчей или выпуска baselines (стабильных релизов) — обращайтесь.

Здравствуйте, Хитрик Денис, Вы писали:

ХД>А не проще научить junior'ов пользоваться branch'ами? И пусть senior даёт отмашку на merge.
а в чём принципиальная разница? ведь результат мержа тоже коммитить нужно.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, stormgt, Вы писали:

S>>Хочу решить две проблемы:
S>>во-первых, обеспечить атомарность коммита.
C>Кстати, а вот для этого лучше использовать SVN или им подобные. Тем более, что в SVN1.5 наконец-то добавили merge tracking.
Согласен. про атомарность коммита я имел в виду CVS.

Здравствуйте, Aquary, Вы писали:

A>Вот здесь я привел краткое описание того, как обычно идет работа с бранчами в команде

Автор: Aquary
Дата: 22.08.07

Спасибо за линк.

A>Конечно, создание бранча — это лишняя пара команд, да и бранчи кто-то должен мержить вместе (СМщик или один из разработчиков) — однако лучшего решения тут нет.
согласен на счёт бранчей для каждого change request.
только мержить ветку, отрезанную для багфикса всё равно прийдётся на рабочую ветку.
А хочется контролировать этот процесс.
Или не заморачиваться с очередью коммитов и давать доступ на стабильную ветку некоторым товарищам?

Здравствуйте, rlabs, Вы писали:

S>>и вторая проблема. есть несколько junior developer'ов. и есть senior.
S>>junior'ы могут коммитить тогда и только тогда, если senior разрешит.
R>Идя таким путем, вы никогда не вырастите из джуниоров инженеров. Когда тебе не доверяют — ты не будешь ответственно относиться к своей работе.
Если рассматривать разрешение на коммит, как акт недоверия, то, безусловно, Вы правы.
Однако, я рассматриваю разрешение на коммит как некую разновидность парного программирования.
Т.е. senior(или другой разработчик) смотрит свежим взглядом и говорит: "вот так-то лучше сделать".
и озвучивает почему.

Здравствуйте, Aquary, Вы писали:

A>Возможно, может показаться резкостью, однако не могу не удивиться тому, как народ пытается вернуться в каменный век... Почему — потому что эта задача давно известна в СМе (configuration management'е) и имеет опробованное годами решение — создание веток (бранчей, branches), как уже сказал в этой ветке Денис Хитрик.

Никаких претензий касательно резкости. Наоборот, конструктивная критика приветствуется

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

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

Если возникало, то поделитесь, плиз инфой, при помощи каких инструментов?

P.S. В наших проектах для доступа к CVS мы используем самодельные скрипты.
хочется понять, есть смысл развивать свою поделку или внедрить уже готовое решение.

Здравствуйте, stormgt, Вы писали:

S>Приветствую!

Использовать какую-нибудь dvc, пусть каждый работает со своим бранчем, когда все ОК — мержить.

Здравствуйте, stormgt, Вы писали:

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

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

S>Если возникало, то поделитесь, плиз инфой, при помощи каких инструментов?
S>P.S. В наших проектах для доступа к CVS мы используем самодельные скрипты.
S>хочется понять, есть смысл развивать свою поделку или внедрить уже готовое решение.

Когда мы использовали CVS на проектах — просто каждый следовал общей политике и коммитил на личные бранчи и осознвал, зачем это делается и почему надо именно так. Т.е. скриптами никак это дело не поддерживалось. А чтобы частично оградить себя от возможных ошибочных коммитов, каждый перед мержем своего бранча или перед коммитом брал последний стабильный релиз и мержил свои изменения с ним. Именно релиз, а не просто последние версии с главных бранчей. Почему — потому что когда выполняющий роль СМщика выдавал новый релиз — он мержил изменения и вешал на полученные версии метку (т.е. "бэйзлайнил" исходники). Тот, кто выбирал исходники по этой метке, мог быть уверен, что даже если кто-то по ошибке закоммитил на главный бранч ошибочно свои зменения поверх, полученные срез исходников был гарантированно стабильным.
Конечно, если идти дальше и всё делать более надежно — надо бы ещё и ограничить возможность только для отдельных людей делать коммиты на гланый бранч. Однако, насколько мне приходилось пробовать, подобная возможность есть только в Clearcase. Там оно сделано на уровне органичения прав на чекаут и внесение изменений для отдельных юзеров для любой отдельно взятой ветки. Если кто найдет подобное решение для CVS или Subversion — скажу спасибо. Однако сдается мне что такое сделать в указанных системах проблематично всвязи с архитектурными ограничениями (разве что сделать прослойку из своих скриптов). Опять же — поправьте меня, если не прав

Но в общем случае — использование веток + выпуск именованных релизов АКА бэйзлайнов решает большинство проблем, подобных описанным в начальной месаге.

Здравствуйте, stormgt, Вы писали:

ХД>>А не проще научить junior'ов пользоваться branch'ами? И пусть senior даёт отмашку на merge.
S>а в чём принципиальная разница? ведь результат мержа тоже коммитить нужно.

Принципиальных отличий я вижу несколько:
1) отсутствие запретов на пользование инструментом — хорошо, это будет способствовать его освоению и более осознанным действиям
2) более частые коммиты в свои бранчи — это хорошо, потому что есть возможность сохранить промежуточный результат своей работы, и даже если он с багами, это не повлияет на работу остальных.
3) senior'у ясно что где находится, у него появляется история изменений с комментариями (см. лог), и он тоже становится застрахованным от ошибки (ведь пока изменения не закоммичены, их можно потерять)
4) по частым коммитам можно отслеживать ход работы

Как-то так

Здравствуйте, Aquary, Вы писали:

A>Вот это уже работа в правильном направлении Просто ты изначально хотел ограничить коммиты любого рода... сейчас вопрос лишь в том, как заставить коммититься на правильную ветку.
Имхо, разницы большой нет : разрешать коммит любого рода или только коммит результата мержа.
про джуниоров привел пример как первый, который пришёл в голову из реальной жизни.

A>Конечно, если идти дальше и всё делать более надежно — надо бы ещё и ограничить возможность только для отдельных людей делать коммиты на гланый бранч.

Если вы про HEAD в случае цвс, то при ограничении доступа на эту ветку никак не добавить новый файл в репозиторий.

A>Однако, насколько мне приходилось пробовать, подобная возможность есть только в Clearcase. Там оно сделано на уровне органичения прав на чекаут и внесение изменений для отдельных юзеров для любой отдельно взятой ветки. Если кто найдет подобное решение для CVS или Subversion — скажу спасибо. Однако сдается мне что такое сделать в указанных системах проблематично всвязи с архитектурными ограничениями (разве что сделать прослойку из своих скриптов). Опять же — поправьте меня, если не прав

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

A>Но в общем случае — использование веток + выпуск именованных релизов АКА бэйзлайнов решает большинство проблем, подобных описанным в начальной месаге.

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

Я правильно понимаю, что тот процесс управления изменениями, который Вы описали в предыд. посте, никаким образом не контролировал возможность\невозможность коммита? Т.е. все знали что так нельзя делать, а так можно и строго следовали этим предписаниям? и что при большом желании любой, имеющий доступ к репозиторию, мог вкоммитить что угодно?

Здравствуйте, stormgt, Вы писали:

S>Я правильно понимаю, что тот процесс управления изменениями, который Вы описали в предыд. посте, никаким образом не контролировал возможность\невозможность коммита? Т.е. все знали что так нельзя делать, а так можно и строго следовали этим предписаниям? и что при большом желании любой, имеющий доступ к репозиторию, мог вкоммитить что угодно?

Именно так. Исключительно из-за отсутствия возможностей у CVS. Но команда была небольшая, все знали что и зачем делается — так что было без осложнений. Последние 2.5 года работаю с Клиркейсом — там всё реализовано правильно, релиз-бранч полностью контролируется СМ-инженерами.

Здравствуйте, Aquary, Вы писали:

A>Именно так. Исключительно из-за отсутствия возможностей у CVS. Но команда была небольшая, все знали что и зачем делается — так что было без осложнений.

Ага, ясно. Спасибо за ответы.

Здравствуйте, Хитрик Денис, Вы писали:

ХД>Принципиальных отличий я вижу несколько:
ХД>1) отсутствие запретов на пользование инструментом — хорошо, это будет способствовать его освоению и более осознанным действиям
ХД>2) более частые коммиты в свои бранчи — это хорошо, потому что есть возможность сохранить промежуточный результат своей работы, и даже если он с багами, это не повлияет на работу остальных.
ХД>3) senior'у ясно что где находится, у него появляется история изменений с комментариями (см. лог), и он тоже становится застрахованным от ошибки (ведь пока изменения не закоммичены, их можно потерять)
ХД>4) по частым коммитам можно отслеживать ход работы

ППКС. Однако, всё же существует опасность того, что кто-то что-то не туда закоммитит не в то время.
Например, два географически разнесённых CMа будут мержить одновременно разные ветки на рабочую(релизную\стабильную etc)
Не приходит в голову другой способ борьбы с подобными проблемами, кроме как организация очереди коммитов.
Неужели ни у кого подобной проблемы не возникает? интересно знать, почему?

Здравствуйте, Cyberax, Вы писали:

C>Почему? Новичок делает checkin, reviewer'ам приходит по почте оповещение, они смотрят через некоторое короткое время. Если что — сразу же по ушам бьют юниора.
Junior: Ну вот, надо чекинить. Сейчас опять начнут бить по ушам...
Reviewer1: Оооо... Новый чекин junor-а, сейчас поглумимся!
Reviewer2: Shit! Опять эти junior-ы не дают работать. Сейчас буду бить по ушам...

Класс, рефлекторное программирование...
Или попытка перенести практики дрессировки медведей в разработку софта.

Здравствуйте, stump, Вы писали:

S>Junior: Ну вот, надо чекинить. Сейчас опять начнут бить по ушам...
S>Reviewer1: Оооо... Новый чекин junor-а, сейчас поглумимся!
S>Reviewer2: Shit! Опять эти junior-ы не дают работать. Сейчас буду бить по ушам...
S>Класс, рефлекторное программирование...
Ага, до тех пор, пока не начнут писать хороший код. На практике не всё так плохо, обычно reviewer'ы понимают, что код пишет junior, и не сильно его бьют.

Зато на джуниоров это оказывает магическое воздействие — где-то через месяц их код проходит review без особых комментариев.

Господа!
Дискуссия слегка зашла в неправильное русло

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

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

Здравствуйте, Cyberax, Вы писали:

C>Зато на джуниоров это оказывает магическое воздействие — где-то через месяц их код проходит review без особых комментариев.

Я предпочитаю развивать в программистах вовлеченность, а не рефлексы. Много эффективней...
Например переходящий вымпел "Build crusher", не отнимает время квалифицированных разработчиков в отличие от постоянного code review, не вызывает у коллег переодических позывов придушить друг друга, становится не нужен обычно уже через две недели (при ежедневных билдах), потому что сама проблема исчезает.

Здравствуйте, stormgt, Вы писали:

S>ППКС. Однако, всё же существует опасность того, что кто-то что-то не туда закоммитит не в то время.

Ну так ошибки можно откатить.

S>Например, два географически разнесённых CMа будут мержить одновременно разные ветки на рабочую(релизную\стабильную etc)
S>Не приходит в голову другой способ борьбы с подобными проблемами, кроме как организация очереди коммитов.
S>Неужели ни у кого подобной проблемы не возникает? интересно знать, почему?

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

Здравствуйте, stump, Вы писали:

C>>Зато на джуниоров это оказывает магическое воздействие — где-то через месяц их код проходит review без особых комментариев.
S>Я предпочитаю развивать в программистах вовлеченность, а не рефлексы. Много эффективней...
Одной вовлечённости мало, если джуниоры будут пихать плохой код. А они точно будут — так как опыта у них мало.

S>Например переходящий вымпел "Build crusher", не отнимает время квалифицированных разработчиков в отличие от постоянного code review, не вызывает у коллег переодических позывов придушить друг друга, становится не нужен обычно уже через две недели (при ежедневных билдах), потому что сама проблема исчезает.
Переходящее знамя — это тот же самый павловский стимул, так что ты не предлагаешь ничего нового.