Здравствуйте, avpavlov, Вы писали:
B>>Типа этого, т.е. главная ветка — это транк. B>>Когда начинается новый проект, отращивается новая ветка и все делается только там.
A>Ни хрена не понял. Новый проект — это отдельное самостоятельное приложение? Или мы слово "проект" с тобой по разному понимаем?
Не совсем понятно, что тебе не понятно...
Новый проект — это это новый проект
Целью проекта обычно является выпуск новой версии софта.
Так вот, когда начинается новый проект, то много чего делается.
В том числе отращивается новая ветка в системе котроля версий.
Одновременно могут быть активными несколько проектов.
B>Типа этого, т.е. главная ветка — это транк. B>Когда начинается новый проект, отращивается новая ветка и все делается только там.
А транк замораживается что ли? Имхо такой вариант немного не по сути SVN, хотя собственно влияет только на название веток.
----
В курсе, что лаврушка и чайный куст — это деревья, лещина/орешник/фундук — это куст, арахис — это бобы, а ананас вообще овощ?
Здравствуйте, VGn, Вы писали:
B>>Типа этого, т.е. главная ветка — это транк. B>>Когда начинается новый проект, отращивается новая ветка и все делается только там.
VGn>А транк замораживается что ли? Имхо такой вариант немного не по сути SVN, хотя собственно влияет только на название веток.
Ну я осознанно не использовал термин "транк", потому что у нас не SVN.
Но суть от этого не меняется.
Подобный подход можно применять с любой системой,
где нормально поддерживаются ветки.
А транк не замораживается.
Это незачем делать, потому что там все равно ничего не происходит.
Только когда проект закончен, то состояние проекта сливается в транк.
Т.е. в транке реально только стабильные версии, естественно помеченные "релизным тагом".
VGn>---- VGn>В курсе, что лаврушка и чайный куст — это деревья, лещина/орешник/фундук — это куст, арахис — это бобы, а ананас вообще овощ?
B>Ну я осознанно не использовал термин "транк", потому что у нас не SVN. B>Но суть от этого не меняется. B>Подобный подход можно применять с любой системой, B>где нормально поддерживаются ветки.
B>А транк не замораживается. B>Это незачем делать, потому что там все равно ничего не происходит. B>Только когда проект закончен, то состояние проекта сливается в транк. B>Т.е. в транке реально только стабильные версии, естественно помеченные "релизным тагом".
Просто транк, он потому и прозван основной веткой (или стволом), потому что в ней и происходят обычно все движения, а релизы наоборот ответвляют в отдельные ветки, которые потом порастают мхом.
Описанный вариант событий, я так понимаю, политикой коротких коммитов назвать трудно. А значит слияние у вас тот ещё секс.
Здравствуйте, VGn, Вы писали:
VGn>Описанный вариант событий, я так понимаю, политикой коротких коммитов назвать трудно.
С чего ты так решил?
В своей ветке могу коммитить хоть каждую минуту.
VGn>А значит слияние у вас тот ещё секс.
Хм... ну я же даже в исходном сообщении написал, что оверхед минимален.
Все конфликты решаются на том уровне, где они возникают.
Т.е. если я как девелопер, намудрил, то проблемы проявятся только в моей ветке
и я вынужден буду их разрешить до того, как я что-то солью со своей ветки
в ветку группы фич.
Конечно, чем меньше координации на проекте, тем больше проблем будет с мерджами.
Если я добавил в интерфейс новый метод, а мой коллега решил,
что интерфейс вообще нафиг не нужен, то проблемы с мерджами гарантированы.
Но тут тебя никакой тул не спасет.
Наш подход только гарантирует, что проблемы, если они возникают,
локализируются очень быстро, они всегда локальны и практически никогда не затрагивают всю команду.
Ну а слияние в транк — это у нас всегда скучнейшая процедура, при которой не возникают никаких проблем.
. Отдельные ветки для фич когда-то использовались, но потом от них за бесполезностью отказались — стали просто использовать две видимые извне ветки, коммитить изменения в рабочую и регулярно обновлять из нее публичную.
И напоследок о тех, кто не использует РСКВ:
In Windows... there are far too many developers to access one central repository. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.
Здравствуйте, Roman Odaisky, Вы писали:
RO>И напоследок о тех, кто не использует РСКВ:
Спасибо за ссылку, любопытно. Причем комменты тоже местами полезны.
Однако, РСКВ в данном случае бы тоже не помогли. Судя по описанию (других источников нет, поэтому получается сугубо ИМХО), проблема в бюрократии и имитации деятельности, а не в иерархии репозиториев. Довелось мне быть участником команды, писавшей код для моторолы. Так вот там, при всей куче народу, делавшего систему большой сложности (для тогдашних телефонов писалась и поддерживалась своя операционка), при всех сложных и порой циклических зависимостя, всё было значительно лучше, чем в приведенном описании. И там использовалась централизованная модель разработки с использованием IBM Rational ClearCase. Разделение на репозитории было минимальным и не иерархическим, а "параллельным", т.е. была репликация центрального репозитрия. И вот в таких жестко центализованных улосиях продукты разарабатывались и выпускались вполне в рамках дэдлайнов.
В общем, как обычно, проблема в статье — не из-за тулов, а из-за организации труда.
Здравствуйте, Aquary, Вы писали:
A>Однако, РСКВ в данном случае бы тоже не помогли. <...> использовалась централизованная модель разработки с использованием IBM Rational ClearCase. Разделение на репозитории было минимальным и не иерархическим, а "параллельным", т.е. была репликация центрального репозитрия.
Чем не имитация распределенных СКВ средствами централизованных?
A>В общем, как обычно, проблема в статье — не из-за тулов, а из-за организации труда.
Оно-то так, но некоторые средства помогают организовать труд и ненавязчиво направляют его в нужную сторону. Если в средствах тяжело merge-ить, то это будут делать редко. Если коммиты тяжеловесны, то же самое. Если нет rebase и история засоряется ненужными слияниями, то ей будут реже пользоваться. Если баги заводить тяжело, то этого будут избегать. И т. д.
Кстати, в Линуксе изменения тоже отнюдь не сразу попадают в mainline, но это никого не волнует, потому что любой может взять себе изменения из любой ветки и потом это будет учтено при слиянии. (Хотя сравнение и не совсем корректно, Линукс ведь только ядро, а в статье наверняка имелась в виду вся ОС, с GUI и прочим.)
Здравствуйте, Roman Odaisky, Вы писали:
RO>Чем не имитация распределенных СКВ средствами централизованных?
Тем, что описанный механизм Multisite не отменяет централизации разработчиков вокруг своей копии базы на сайте (т.е. местоположении команды). И к этой копии они обращаются централизованно. Кроме того, существует жесткая система авторизации для каждого сайта, и пользователь с одного сайта далеко не всего может обратиться к другой базе — для этого ему дать соответствующие права. Сам Multisite не является обязательным к использованию. Без него каждый отдельный сайт работает как централизованное целое. В распределенных же системах каждый делает что хочет и при необходимости обращается к любому из репозиториев.
A>>В общем, как обычно, проблема в статье — не из-за тулов, а из-за организации труда.
RO>Оно-то так, но некоторые средства помогают организовать труд и ненавязчиво направляют его в нужную сторону. Если в средствах тяжело merge-ить, то это будут делать редко. Если коммиты тяжеловесны, то же самое. Если нет rebase и история засоряется ненужными слияниями, то ей будут реже пользоваться. Если баги заводить тяжело, то этого будут избегать. И т. д.
Согласен — человек должен работать не вопреки, а благодаря тузлам. Однако большинство сегодняшних систем контроля достаточно зрелы, чтоб рассматривать не их недостатки, а модели разработки на их основе.
RO>Кстати, в Линуксе изменения тоже отнюдь не сразу попадают в mainline, но это никого не волнует, потому что любой может взять себе изменения из любой ветки и потом это будет учтено при слиянии. (Хотя сравнение и не совсем корректно, Линукс ведь только ядро, а в статье наверняка имелась в виду вся ОС, с GUI и прочим.)
Собственно, сложно ожидать от такой огромной системы отсутствия промежуточных стадий сборки и проверки. Разумеется, код должен предварительно отстаиваться, ревьюиться — и делается это явно не на mainline.
В описанном подходе Майкрософта есть своё рациональное зерно, задумано всё очень интересно. Однако — неповоротливость самой компании всё губит. Думаю, у них и любая DVCS так же пролегла бы пропастью между командами, ставя лишние преграды для взаимодействия.
В общем, подход МС и подход команды ядра линукса суть две противоположности организации контроля версий. Однако проистекают они из принципиальной разницы самой модели разработки, отсюда и такая разница в средствах.
Здравствуйте, Aquary, Вы писали:
RO>>Чем не имитация распределенных СКВ средствами централизованных?
A>Тем, что описанный механизм Multisite не отменяет централизации разработчиков вокруг своей копии базы на сайте (т.е. местоположении команды). И к этой копии они обращаются централизованно. Кроме того, существует жесткая система авторизации для каждого сайта, и пользователь с одного сайта далеко не всего может обратиться к другой базе — для этого ему дать соответствующие права. Сам Multisite не является обязательным к использованию. Без него каждый отдельный сайт работает как централизованное целое. В распределенных же системах каждый делает что хочет и при необходимости обращается к любому из репозиториев.
РСКВ часто так и работают, см. ниже.
A>Собственно, сложно ожидать от такой огромной системы отсутствия промежуточных стадий сборки и проверки. Разумеется, код должен предварительно отстаиваться, ревьюиться — и делается это явно не на mainline.
A>В описанном подходе Майкрософта есть своё рациональное зерно, задумано всё очень интересно. Однако — неповоротливость самой компании всё губит. Думаю, у них и любая DVCS так же пролегла бы пропастью между командами, ставя лишние преграды для взаимодействия.
РСКВ с легкостью позволяют организовать многоуровневую иерархическую структуру, при которой maintainer’ы собирают изменения своих «подчиненных» и передают их выше. При этом инфраструктура тестирования, code review и т. п. может быть в нескольких местах. В то же время описанная майкрософтовская иерархия выглядит попыткой натянуть одну ЦСКВ на огромную команду, для чего их средства не предназначены.
A>В общем, подход МС и подход команды ядра линукса суть две противоположности организации контроля версий. Однако проистекают они из принципиальной разницы самой модели разработки, отсюда и такая разница в средствах.
Не соглашусь. В чём разница-то? В Линуксе команды независимы и удалены одна от другой, но и в Windows тоже. В Линуксе изменения плавно всплывают наверх, откуда их все потом берут, в Windows тоже. В Линуксе есть своя собственная СКВ, в Windows тоже — только git распределенный, а TFS нет.
Здравствуйте, Roman Odaisky, Вы писали:
A>>Тем, что описанный механизм Multisite не отменяет централизации разработчиков вокруг своей копии базы на сайте (т.е. местоположении команды). И к этой копии они обращаются централизованно. Кроме того, существует жесткая система авторизации для каждого сайта, и пользователь с одного сайта далеко не всего может обратиться к другой базе — для этого ему дать соответствующие права. Сам Multisite не является обязательным к использованию. Без него каждый отдельный сайт работает как централизованное целое. В распределенных же системах каждый делает что хочет и при необходимости обращается к любому из репозиториев.
RO>РСКВ часто так и работают, см. ниже.
Не соглашусь. Идея DVCS — отход от централизованной работы, приоритет — обмену дельтой между произвольными нодами, а центральные репозитории служат лишь для создания baselines. CVCS настаивают на том, что произвольных нод быть не должно, а реплики репозитория — лишь способ масштабировать базу.
RO> В то же время описанная майкрософтовская иерархия выглядит попыткой натянуть одну ЦСКВ на огромную команду, для чего их средства не предназначены.
Я бы сказал: иерархия — следствие метода организации работы в целом, а натягивание централизованной системы на эту структуру — лишь следствие. И если заменить CVCS на DVCS — ничего бы не поменялось, т.к. организация работы команд в целом осталась бы той же.
RO>Не соглашусь. В чём разница-то? В Линуксе команды независимы и удалены одна от другой, но и в Windows тоже. В Линуксе изменения плавно всплывают наверх, откуда их все потом берут, в Windows тоже. В Линуксе есть своя собственная СКВ, в Windows тоже — только git распределенный, а TFS нет.
Описанный случай относится к 2006 году, тогда (а возможно и сейчас) использовали систему контроля SourceDepot, основанную на Perforce.
Насчет удаленных команд — отчасти это так. Однако если в Линуксе распределенность изначально была фактом, то в МС это лишь одно из обстоятельств, появивщихся со временем. В целом же система работы построена на централизацию и тесное взаимодействие; циклические зависимости, упомянутые в комментах, — как раз следствие такого централизованного подхода. Для Линукса их в принципе нет, т.к. разработчики ядра изначально наверняка понимали, что не смогут ими эффективно управлять (по крайней мере, в первые годы работы).
Pzz>>Сорс контрол, конечно, обладает кроме всего прочего функцией бакапа, но это далеко не самое важное его свойство и даже не одно из основных.
Q>Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Бэкап ортогонален SCM. Это совершенно разные задачи и уровни оперирования данными.
Если на винте с SCM умрет (по физическим/программным и т.п. причинам) некоторое кол-во секторов, то весь сорс-контрол накроется медным тазом, если бэкапов не было. Уповать на то, что "у девелоперов есть локальные копии" — не панацея по многим причинам (какую из них считать самой истинной, откуда выцарапывать историю в случае централизованного репозитория и т.п.).
Q>В моём мире — всё что может делать автоматика, лучше ей и доверить. Программист пусть свободное время на зарядку потратит.
Здравствуйте, Аноним, Вы писали: А>"у девелоперов есть локальные копии" — не панацея по многим причинам (какую из них считать самой истинной, откуда выцарапывать историю в случае централизованного репозитория и т.п.).
Про локальные копии обычно упоминают в контексте dvcs. Там с историей все в порядке. И абсолютно не важно, какую локальную копию положить на новый центральный сервер в случае смерти старого.
