Не так давно (примерно в начале 2008 года) на горизонте ИТ появился новый buzzword - DVCS (distributed version control systems). Особенно часто в контексте DVCS упоминаются Git, Mercurial и Bazaar.
Зачем они нужны и как коррелируют с традиционными VCS (SVN, CVS, VSS и др.) неплохо изложено в статье на InfoQ.
Я хотел бы задать ряд вопросов читателям этого блога:
Зачем они нужны и как коррелируют с традиционными VCS (SVN, CVS, VSS и др.) неплохо изложено в статье на InfoQ.
Я хотел бы задать ряд вопросов читателям этого блога:
смысл есть - выныривать из анабиоза иногда
ОтветитьУдалитьЕсли относиться как к buzzword, то нунафик. Слишком поверхностный подход получится.
ОтветитьУдалитьЯ перешел, теперь со слезами смотрю на те места где приходится использовать SVN. Хотя бы даже возможность коммита оффлайн уже приятно. Раньше приходилось крутить педали, а теперь сел и поехал туда куда хочется, по ощущениям.
Прочитал книгу про Mercurial и навсегда фанат концепции DVCS.
По безопасности почитай таблицы стравнения, в основном ее нет, потому что не обязательно класть все в один репозиторий.
Свои мысли изложил на прошлой неделе, посмотри комментарии к постам:
Системы контроля версий
Why not Git
@Lis: Главное не стать Астронавтом.
ОтветитьУдалить@xenru: Уже много лет на SVN. Все в принципе устраивает, кроме "merge hell". Надеялся найти решение в DVCS, но не нашел :( Может не там искал.
ОтветитьУдалитьПо поводу buzzword: я имел в виду, что мне шум вокруг DVCS напоминает тоже самое, что было в свое время вокруг Java, .Net, ESB, Grid computing, а сейчас происходит по поводу Cloud computing. По поводу последнего неплохо прошелся Ross Mason.
в DVCS объединение веток (merge) -- это одна из основных операций, наравне со всеми остальными. Поэтому если в DVCS вы увидели merge hell -- такая DVCS сразу должна отправляться в мусорку.
ОтветитьУдалитьЯ использую bzr, и честно говоря переходить на другие (тем более svn) не вижу смысла. А если сильно нужно svn, то можно задействовать плагин bzr-svn и делать вид, что svn -- это тоже bzr-ветка :-)
@bialix: Я в курсе, что гибкий merge как и off-line commits, это важная часть DVCS.
ОтветитьУдалитьЧто не устраивает в SVN: у Вас есть trunk, с которого в разные периоды наделано branch-ей. В них ведутся иногда доработки (у вас есть продукт версии X и его предыдущие версии X-1, X-2 и т.д.). Есть клиенты на разных версиях продукта: X, X-2 и т.д. Есть develop-ерские branch-и. Они merge-атся в trunk и иногда в предыдущие версии (X-1, X-2 и т.д.). Задача стоит следующая: узнать какие merge-и были сделаны из develop-ерских branch-ей и в какие версии.
Усложняем задачу :) Проектов много, они взаимосвязаны. Над проектами работают разные сотрудники и давать права всем коммитить всюду не хочется по целому рядку причин.
Как это все "ложится" в концепцию DVCS - не понимаю. Точнее понимаю, но "maintenance hell" этого хозяйства, мне кажется будет хуже, чем с SVN.
> Задача стоит следующая: узнать какие merge-и были сделаны из develop-ерских branch-ей и в какие версии.
ОтветитьУдалитьЕсли не брать случай cherrypicking, то получить ответ на вопрос: "была ли замержена ветка А в ветку Б" элементарно просто в случае DVCS. Потому что они отслеживают это все сами. Они просто обязаны это делать.
> Усложняем задачу
Извините, но вы ищете техническое решение для социальной проблемы. Это решается только организационными методами. Выделите человека на каждый проект. который будет менеджером главной ветки проекта. Пусть все merge идут через него. Для развлечения почитайте UQDS.
> Как это все "ложится" в концепцию DVCS
Не знаю. Похоже вам нужна серебрянная пуля.
@bialix: Спасибо за UQDS. У нас сейчас введен похожий подход, но жизнь оказывается хитрее :), особенно когда идут паралелльные разработки над одним и тем же проектом разными командами (или когда идет перенос изменений в предыдущие версии).
ОтветитьУдалитьНу а по поводу "пули" - да, любим Фредерика Брукса и ждем серебрянной пули.