Приветствую!
Возникла необходимость организовать очередь коммитов,
т.е. чтобы предовратить одновременный коммит несколькими пользователями.
процесс мне видится так: пользователи создают запросы на коммит.
cvs admin разрешает коммит пользователю, отправившему запрос первым.
если админ разрешил коммит определённому пользователю,
то он и только он может коммитить изменения до тех пор,
пока не будет удалён из очереди.
Подскажите, плиз,существуют ли готовые решения для cvs/svn, позволяющие реализовать вышеописанную процедуру?
Здравствуйте, stormgt, Вы писали:
S>Возникла необходимость организовать очередь коммитов, S>т.е. чтобы предовратить одновременный коммит несколькими пользователями.
Здравствуйте, rlabs, Вы писали:
S>>т.е. чтобы предовратить одновременный коммит несколькими пользователями. R>А можно в двух словах — зачем это?
Для code review или тестов, скорее всего.
Здравствуйте, rlabs, Вы писали:
R>А можно в двух словах — зачем это?
Хочу решить две проблемы:
во-первых, обеспечить атомарность коммита.
Т.е. один человек коммитит багфикс.
после этого прогоняются тесты и строится билд.
если билд свалился или тесты не прошли, то очевидно, кто сломал всё
и вторая проблема. есть несколько junior developer'ов. и есть senior.
junior'ы могут коммитить тогда и только тогда, если senior разрешит.
Здравствуйте, 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), а на отдельный бранч!
Конечно, создание бранча — это лишняя пара команд, да и бранчи кто-то должен мержить вместе (СМщик или один из разработчиков) — однако лучшего решения тут нет.
Если есть вопросы по политике ведения бранчей или выпуска baselines (стабильных релизов) — обращайтесь.
Здравствуйте, Хитрик Денис, Вы писали:
ХД>А не проще научить junior'ов пользоваться branch'ами? И пусть senior даёт отмашку на merge.
а в чём принципиальная разница? ведь результат мержа тоже коммитить нужно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, stormgt, Вы писали:
S>>Хочу решить две проблемы: S>>во-первых, обеспечить атомарность коммита. C>Кстати, а вот для этого лучше использовать SVN или им подобные. Тем более, что в SVN1.5 наконец-то добавили merge tracking.
Согласен. про атомарность коммита я имел в виду CVS.
Спасибо за линк.
A>Конечно, создание бранча — это лишняя пара команд, да и бранчи кто-то должен мержить вместе (СМщик или один из разработчиков) — однако лучшего решения тут нет.
согласен на счёт бранчей для каждого change request.
только мержить ветку, отрезанную для багфикса всё равно прийдётся на рабочую ветку.
А хочется контролировать этот процесс.
Или не заморачиваться с очередью коммитов и давать доступ на стабильную ветку некоторым товарищам?
