Здравствуйте, Ytz, Вы писали:
AD>>7) Отправить запрос на интеграцию, пусть мержат в основную ветку Ytz>То есть не решаем проблему разрешения конфликтов, а просто переносим проблему на другой уровень Кстати Линус в своем интервью сказал что-то вроде: "Какая же это проблема? Я знаю, что большинство комитеров идиоты и просто их комиты не буду смотреть"
Нет, не так. Проблема разрешения конфликтов разрешается еще до СКВ (не путать со свободно конвертируемой валютой ). Я опишу тот процесс, который у нас был на ClearCase. В ClearCase, в отличие от того же SVN, история не линейна. У каждого элемента (файла/директории) своё дерево веток и версий, при чем основной меткой может служить любая ветка и их может быть несколько. Собственно, для ClearCase все ветки равнозначны. И совсем нет коммитов. Определенный срез файлов (view) задается набором правил(configuration specification), где просто перечисляются файлы, их ветки и версии на этих ветках:
# My dev branches/rules
element /project_path/... /main/product_XXX/my_branch/LATEST
# Release rules
element /project_path/Makefile /main/product_XXX/14
element /project_path/src /main/product_XXX/10
element /project_path/src/file.c /main/product_XXX/7
element /project_path/src/... /main/product_XXX/LATEST
Так же любой срез можно пометить меткой для упрощения config-spec:
# My dev branches/rules
element /project_path/... /main/product_XXX/my_branch/LATEST
# Release rules
element * PRODUCT_XXX.V1.02.BUILD_2321
Все, что выше, я написал, чтобы было понятно, что такое метка в моем случае.
Есть продукт, он очень большой и девелопится множеством команд на множестве сайтов по всему миру. Отдельные команды отвечают за один или несколько компонент.
С точки зрения configuration management есть:
1) Продуктовая метка.
2) Компонентная метка для каждого отдельного компонента.
Метки выпускаются, ну допустим, раз в неделю. Компоненты собирают все изменения от девелоперов, объединяют это в релиз компонента (метку) и фигачат этот релиз в продуктовую метку.
Продуктовая метка подсасывает в себя все последние компонентные метки и также выпускает новый продуктовый релиз (метку).
Так и живем изо дня в день
Никто, кроме нашей команды, вносить изменения в наш компонент не может. Но желающие без проблем могут присылать нам свои фиксы, какие-либо запросы на изменения, запросы на новый API и т.д., которые мы уже сами вносим.
Соотвественно компонент сам по себе тоже немаленький и за каждую подсистему отвечает один человек (pilot) с несколькими помощниками (co-pilot). Здесь проще. Любой член нашей команды в принципе может менять любые исходники по необходимости. Но на code review обязательно должен присутствовать pilot той подсистемы, куда были внесены изменения.
Итак сам процесс выглядит примерно так:
1) На меня назначают issue в багтрекере.
2) Я беру нашу последнюю метку, отращиваю свою метку и делаю багофикс.
2.1) В то же самое время мой помощник делает другой багофикс в этой же подсистеме.
2.2) В это же время другой pilot ваяет новую фичу и затрагивает часть файлов из моей подсистемы.
2.3) На всем этом промежутке мы трое постоянно общаемся и я знаю, что и как собираются делать двое моих коллег. Собственно конфликты разруливаются уже здесь.
3) Я закончил свой багофикс и приглашаю нескольких человек принять участие в code-review. Одновременно, я участвую как reviewer в инспекциях кода двух моих коллег и я знаю, что никаких аццких глобальных изменений они не делали. Если вдруг сделали, то изменения я просто не одобрю, либо мы все трое синхронизируемся как следует.
4) Инспекции закрываются, замечания (если есть таковые) исправляются.
5) Мы трое подаем запросы на интеграцию.
6) Наш CM-инженер собирает в кучу наши изменения. Если здесь возникают какие-то конфликты, то они тривиальны и CM-инженер сам их разруливает. CM-инженер так же отклоняет любые изменения, которые не были одобрены пилотом соответствующего компонента.
7) CM-инженер строит код со всеми изменениями. Все проблемы с падающими билдами решаются тут же со всеми участниками.
8) Отстроенный продукт отдается на тестирование. Если что-то поломалось, то ищется злосчастный запрос, который и выкусывается, тогда итерация повторяется.
9) Релиз оттестирован. CM-инженер завершает мерж в ветку продукта, помечает срез меткой и пуляет нашу метку в продуктовую метку.
Здравствуйте, andrey.desman, Вы писали:
AD>Итак сам процесс выглядит примерно так:
[skip]
Примеро аналогичный процесс действует в других проектах с git'ом — там за merge изменений в центральные ветки отвечает их maintainer. Другое дело, что это может создать bottleneck'и на нём.
Здравствуйте, Cyberax, Вы писали:
C>Примеро аналогичный процесс действует в других проектах с git'ом — там за merge изменений в центральные ветки отвечает их maintainer. Другое дело, что это может создать bottleneck'и на нём.
Хм. Возможно. Но я с этим не сталкивался. Вообще, maintainer проверяет и сливает изменения быстрее, чем девелоперы могут писать код, если конечно их не тысячи на одного. Если проект большой, то соответственно и людей с правом голоса/мержа должно быть больше, т.е. надо делать разбивку на подсистемы. Если бы на android был всего один maintainer, то это было бы печально
Здравствуйте, Sinix, Вы писали:
S>Вполне возможно, внутре оно прекрасно, но как быть с окружением?
Центральный реп на gitosys. Интеграция с багтрекером/нотификаторы по мылу/jabber через хуки. Всякие проверки перед коммитом (стиль, связь с issue, да хоть чтоб пробелов лишних не было) — тоже через хуки. Локально или на сервере.
S>В результате контроль версий у нас just works, без камланий на мануал и (главное) без обучения чему-либо для пользующихся.
Обучение Git-у сравнимо с обучением svn-у. IMHO.
S>Для git — ?
На работе пользуюсь git-svn, соответственно локальные правки делаю в локальных ветках, затем мёржу в мастер и лью. Если при мёрже конфликт (кто-то уже залил что посвежее) — очень просто сделать rebase. В svn этой проблемы нет только потому, что там нет и огромного преимущества — локальных веток. Что-то сделал в соседней ветке — очень лёгкий cherry-pick и изменения в другой ветке. Не нравится история — rebase и получаешь то, что надо. Интерактивный rebase для простых случаев (слить коммиты, поменять коммит, удалить коммит) — рулит. Всё, что я хочу проверить/сделать — проверяет/делает Git хуками.
Здравствуйте, mkizub, Вы писали:
M>Я работал с перфорсом, и он мне понравился (в отличие от глюкодрома ClearCase). M>Из бесплатных, svn вне конкуренции. С git я тоже мучался. Даже освоил хождение по стандартному пути. M>Но ужасы с попыткой отойти чуть вправо-влево не помещаются в моё сознание.
Развернёшь?
M>Преимущества в распределённости репозитория я просто не заметил.
Грубо говоря, из-за того, что реп находится локально и работа с ветками очень лёгкая — ты можешь менять историю как тебе вздумается. Из-за этого работа ведётся на совершенно ином уровне нежели в svn. Т.е. если ты с Git работал как с svn, то преимуществ не заметишь, да.
Здравствуйте, mkizub, Вы писали:
M>Преимущества в распределённости репозитория я просто не заметил. Только при необходимости вносить свои изменения в код из чужих репозиториев, чтоб не ждать, когда они поправят засабмиченные баги. Это чуть удобнее, чем в svn-е руками делать merge. Всё. M>Зато вправо-влево в svn-е делается легко и понятно. Без бубнов. Описано в доке. В 90% уже умеется в виде нажатия кнопки в TortoiseSVN и т.п.
Попробуй Mercurial — там распределенность, но зато прекрасная документация, описывающая что когда зачем и почему, плюс названия команд аналогичны svn-овским (там, где это возможно), что облегчает использование.
Здравствуйте, Константин, Вы писали:
К>Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну
Если не секрет, что это за проект такой, что в одном репозитарии 11.5Gb исходников?
Здравствуйте, Константин, Вы писали:
C>>1) Он быстрый. F>>на каком объеме исходников это становится заметно?.
К>Исходники 175Mb, 24 тысячи файлов, .git — 88Mb. Здесь хорошо заметно преимущество git в скорости. К>Исходники 650Mb, 16 тысяч редко изменяемых файлов, .git — 150Mb. git тянет нормально. Мercurial не пробовал. К>Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну
Что-то не вставляет меня такое сравнение. Не очень понятен первый пункт — там все же запускался Mercurial? И насколько "хорошо заметно" превосходство git?
Пункт 2 и 3 — это это просто вырезать и повесить на рамочку как пример идеального сравнения — "Система А работает, Систему Б я даже не пробовал запускать, значит А — лучше, лучше, лучшееееее!!!!"
Как-то скорость Mercurial тоже в обзорах никогда не ругают. Структура репозитория у него тоже оптимизирована на быстрое извлечение любой ревизии файла — в общем случае чуть медленее, чем git из-за поддержки хранения разниц, но за счет постоянного присутствия "мастер-кадров" время построения нужной версии близко к постоянному, в отличии от SVN, где файлы с длинной историей могут строиться очень долго.
Зато получается, что объем репозитория у mercurial должен быть меньше, причем безо всяких шаманств с репаком.
DC>Да я то и сейчас с MKS-ом из vim-а и консоли работаю, вопрос в том, что абсолютное большинство людей в нашей конторе работают под виндой.
У нас в конторе, кроме MKS-а, несколько команд используют еще и SVN.
Как минимум одна из команд использует один репозиторий на 2 украинских офиса и на Польшу.
Так что по поводу SVN-а есть у кого консультироваться.
Но если выберете mercurial или git, то будет интересно узнать про процесс перехода и его результаты.
... AD>Есть продукт, он очень большой и девелопится множеством команд на множестве сайтов по всему миру. Отдельные команды отвечают за один или несколько компонент. AD>С точки зрения configuration management есть: AD>1) Продуктовая метка. AD>2) Компонентная метка для каждого отдельного компонента.
... AD>5) Мы трое подаем запросы на интеграцию. AD>6) Наш CM-инженер собирает в кучу наши изменения. Если здесь возникают какие-то конфликты, то они тривиальны и CM-инженер сам их разруливает. CM-инженер так же отклоняет любые изменения, которые не были одобрены пилотом соответствующего компонента. AD>7) CM-инженер строит код со всеми изменениями. Все проблемы с падающими билдами решаются тут же со всеми участниками.
... AD>8) Отстроенный продукт отдается на тестирование. Если что-то поломалось, то ищется злосчастный запрос, который и выкусывается, тогда итерация повторяется. AD>9) Релиз оттестирован. CM-инженер завершает мерж в ветку продукта, помечает срез меткой и пуляет нашу метку в продуктовую метку.
Моторола, SEI-CMMI5
Это все прекрасно работает, когда есть монстроузный проект (начинка телефона) и в нем надо делать какие-то косметические изменения. Да еще нужно содержать целую ораву сертифицированных админов чтобы обслуживать VOB-ы.
Здравствуйте, Vladimir Bezugliy, Вы писали:
VB>У нас в конторе, кроме MKS-а, несколько команд используют еще и SVN. VB>Как минимум одна из команд использует один репозиторий на 2 украинских офиса и на Польшу. VB>Так что по поводу SVN-а есть у кого консультироваться.
Это я знаю, но у них очень простой случай. Нам же надо решить, в итоге, значительно более сложную задачу.
VB>Но если выберете mercurial или git, то будет интересно узнать про процесс перехода и его результаты.
Ну mercurial мне пока меньше всего понравился, bazaar интересен набором готовых рецептов и официальной платной поддержкой (но что-то после 2х годичного использования продуктов Canonical есть ощущение, что не смотря на всю "гламурность" придётся работать напильником и паяльником). Пока у меня в фаворитах git за счёт совей скорости и кастомизируемости, но время покажет что у нас получится.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, alsemm, Вы писали:
A>Здравствуйте, Константин, Вы писали:
К>>Исходники 11.5Gb, 6 тысяч файлов, .git — 7.7Gb (в основном редко изменяемые бинарные файлы). git чуть тормозит, но работать можно. Mercurial использовать не рискну A>Если не секрет, что это за проект такой, что в одном репозитарии 11.5Gb исходников?
Это не исходники в смысле исходного кода. Скорее это наборы тестовых данных, которые крайне редко, но всё-таки меняются.
Здравствуйте, vladimird, Вы писали:
DC>>Это я знаю, но у них очень простой случай. Нам же надо решить, в итоге, значительно более сложную задачу.
V>В чем сложность? V>В поддержке кучи веток?
Куча веток это одна из проблем. Вообще в идеале, хочется создать удачный прецедент и набор готовых решений для перехода других юнитов. Т.е. хочется и конвертер истории и интеграцию с существующей MKS инфраструктурой.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
DC>Куча веток это одна из проблем. Вообще в идеале, хочется создать удачный прецедент и набор готовых решений для перехода других юнитов. Т.е. хочется и конвертер истории и интеграцию с существующей MKS инфраструктурой.
У нас каждая команда сама по себе создает такие прецеденты и пишет велосипеды
Мы сейчас тоже что-то подобное собираемся делать(вернее переделать имеющееся) для конвертации SVN -> MKS.
Основная переделка — поддержка бранчей/вариантов.
Правда у нас команда нераспределенная. Все сидим в одном офисе. Пока
Но пока не будет команды сверху, то все велосипеды так и останутся велосипедами
Здравствуйте, lomeo, Вы писали:
L>Обучение Git-у сравнимо с обучением svn-у. IMHO.
Повторю: без обучения чему-либо для пользующихся. Просто стандартное окно Pending changes в студии. Для нетривиальных случаев — контекстные меню (основная грабля с анком и была в раскидывании пунктов таким образом чтобы спрятать опасные фичи поглубже и сделать нужное легконаходимым).
L>На работе пользуюсь git-svn, соответственно локальные правки делаю в локальных ветках, затем мёржу в мастер и лью. Если при мёрже конфликт (кто-то уже залил что посвежее) — очень просто сделать rebase. В svn этой проблемы нет только потому, что там нет и огромного преимущества — локальных веток. Что-то сделал в соседней ветке — очень лёгкий cherry-pick и изменения в другой ветке. Не нравится история — rebase и получаешь то, что надо. Интерактивный rebase для простых случаев (слить коммиты, поменять коммит, удалить коммит) — рулит. Всё, что я хочу проверить/сделать — проверяет/делает Git хуками.
Отдельные слова понятны (поскольку дежурный по глюкам окружения). Сосед сделал круглые глаза и поинтересовался почему низзя просто работать и "сохранять в репозиторий по кнопке".
Прелесть именно в том что люди тратят время на полезные вещи а не на повышение ЧСВ.
Здравствуйте, vladimird, Вы писали:
V>У нас каждая команда сама по себе создает такие прецеденты и пишет велосипеды
Да, насколько я понял, BU у нас много, а вот SVN используют только новые, которые с самого начала на нём процесс построили.
V>Мы сейчас тоже что-то подобное собираемся делать(вернее переделать имеющееся) для конвертации SVN -> MKS. V>Основная переделка — поддержка бранчей/вариантов.
Бранчи то будут, сливать эти бранчи и перекидывать между ними коммиты в SVN-е довольно геморно, в смысле руками делать надо будет.
А с DCVS можно настроить более гибко:
1. Сделать набор скриптов чтоб девелопер мог использовать DCVS как локальный репозиторий, а MKS — используется для взаимодействия с другими.
2. Поменять эти скрипты так, чтоб этот репозиторий мог использоваться всей командой, а MKS — только для взаимодействия с другими коммандами.
3. MKS зеркало только для отчётности.
Хотя SVN, в принципе, может стать ступенькой, т.к. git/mercurial/bazaar поддерживают вытягивание истории из SVN-а.
V>Правда у нас команда нераспределенная. Все сидим в одном офисе. Пока
V>Но пока не будет команды сверху, то все велосипеды так и останутся велосипедами
Надо показать им преимущества. Мне, например, чтоб залиться на Днепропетровский сервак (10-20 файлов) надо не менее 1,5 часов потратить на просмотр окошек и статус баров MKS-а. Сам понимаешь это очень много, да и Днепропетровске тоже времени не мало уходило, т.к. нельзя одной командой просмотреть объем изменений, дифы и залить. Прыганье по папкам тоже занимает время.
В крайнем случае мы просто облегчим жизнь себе .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, alsemm, Вы писали:
A>Моторола, SEI-CMMI5
Она самая
A>Это все прекрасно работает, когда есть монстроузный проект (начинка телефона) и в нем надо делать какие-то косметические изменения.
Что касается косметических изменений, то все совсем наоборот. Слишком много геммороя на ровном месте из-за нескольких строк. А вот для более существенных изменений этот процесс работает как надо. Просто моторка, как и почти всякая крупная компания, не обладает достаточной степенью мобильности и гибкости.
В принципе, примерно так же оно работает и в linux kernel (читаем про лейтенантов тут).
Ну а вариаций вообще дофига.
A>Да еще нужно содержать целую ораву сертифицированных админов чтобы обслуживать VOB-ы.
А то! Именно поэтому git рулит Сам себе админ.
Кстати Линус в своем интервью сказал что-то вроде: "Какая же это проблема? Я знаю, что большинство комитеров идиоты и просто их комиты не буду смотреть" 
