Здравствуйте, 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, не вызывает у коллег переодических позывов придушить друг друга, становится не нужен обычно уже через две недели (при ежедневных билдах), потому что сама проблема исчезает.
Переходящее знамя — это тот же самый павловский стимул, так что ты не предлагаешь ничего нового.