О славной системе контроля версий. Vivat, Bazaar!

Когда услышал о ней от Александра Бельченко (bialix) на exception.org.ua — пожал плечами. Я уже не представлял себе жизнь без version control system, и считал, что subversion (svn) — то, что надо. И лучше — не придумаешь. Ведь SVN — это тот же CVS (отличная штука, пользовался) — но только без всех раздражающих недоработок. Время, затрачиваемое на нее уменьшается почти до незаметного. А польза — очевидна. Куча плагов и настроек. И trac с этим зверем — родной. А самое главное — все ребята, с которыми приходилось работать, осваивали ее без труда. Правда. Даже художники (у них голова повернута немного не в ту сторону, кто знает — поймет). Культура работы возросла, и практически исчезло время на согласование «версии у меня и у тебя». И блокировок нет — чур-чур SourceSafe и AlienBrain. А еще консольный интерфейс простой как бубен и удобный как тапочки. А если его не хватает (для художников важно) — есть tortoise svn. А еще pysvn — как же удобно! И куча других GUI систем. А еще — даже sourceforge.net его поддерживает (есть куда выкладывать свой OpenSource)

Чего же еще требовать и что искать? Новый велосипед?

Но присматривался ревниво — а вдруг? Хоть и пугала идея РАСПРЕДЕЛЕННОЙ разработки. Непонятная какая-то.

Но тут жизнь переменилась. Ушел с работы, другую не захотел искать быстро. Появилось свободное время. Потом маятся бездельем надоело, да и подработок небольшой оказалось найти недолго...

Но без системы контроля версий жить уже не мог. Неуверенно себя чувствовал. Поднимать локально svn — можно, но смешно. А еще я все-таки смотрел, что там базаровцы делают...

И в качестве эксперимента — попробовал.

Сначала — локально (знаете ли, для bzr не обязателен даже сервер). Commit — add — mv — status — log — diff — export. Цепочка прошла «на ура». Я даже забывался и пытался писать svn ci -m «fixed something» вместо bzr ci -m «fixed something». Несколько секунд пялился на ошибку и понимал, что я уже не в svn :) Общее ощущение — консоль еще проще, чем в svn. Куда полнее распознает мои файлы (еще меньше нужно включать в ignore list, да и само включение проще. Нужные команды обрели элементарный вид, а лишние — исчезли). Не нужно говорить svn remove — bzr сам понимает, какие файлы я удалил. А bzr mv осталась — понимаю почему.

Потом — чуть сложнее. Синхронизация работ. Тоже — легче простого, Когда у каждого по своей ветке. В svn ветки заводят по серьезной причине, а в bzr — просто так. Взял у кого-то версию библиотеки — и вот у тебя уже ветка. Будет она выкладываться в инет или останется личной — как знать. Если нет — будет только моей, и сервер о ней ничего не узнает. Эта свобода поначалу пугала — потом привык.

То, что код склеивается (merged) без проблем — привычно, избалован svn. Лучше или хуже — не знаю. Достаточно хорошо.

Естественно, стало интересно, а как у bzr с серверами? Оказалось — не хуже, чем в svn. Т.е. так же по привычному — работать можно. Можно и чуть удобнее — bzr unbind, bzr commit, commit, commit... И снова — bzr bind. С синхрнизацией проблем нет. Есть еще много занятных способов организации работы — я их еще не пробовал.

Но то, что с svn ОЧЕНЬ ЛЕГКО перейти на bzr, при этом не ощутив неудобств, но приобретя дополнительную свободу — факт.

TortoiseBzr уже есть. Как некоторое количество GIU сред. Есть поддержка под ряд IDE (список уточняйте, я их не использую). Есть кое-какая поддержка в trac. Aaron делает полностью свой аналог, отражающий новый стиль разработки. Бета работает, вырастет из этого что-то доброе и хорошее. Есть и launchpad.net — bzr хостинг для OpenSource проектов.

Что из минусов? Должны же быть? Конечно есть. Проект еще относительно молодой. Ядро работает очень стабильно, нареканий нет. Но могут быть проблемы с «мясом» — трекерами, GUI примочками и прочей инфраструктурой. Я не испытал — так потому, что люблю консоль прежде всего. Проблемы решаются и довольно быстро исчезнут. Люди работают. Над тем же для svn работают гораздо дольше.

Есть беда с русской документацией. Ее практически нет. Эхх, если бы bialix занялся... С «просто документацией» тоже не все гладко. У svn куда более мощный пакет. И это понятно. Но скоро, думаю, все будет.

А теперь, как водится, резюме. Лично мне очень понравилось, и намерен использовать дальше. Дает дополнительную свободу по сравнению с svn и перекрывает его полностью. Развивается в нужную сторону, и скоро станет наравне с «законодателями моды», а им прийдется потесниться. Лично мне понятие «моды» в программировании чуждо, а bazaar предложил отличную альтернативу.

И, наконец, мне просто с ним УДОБНЕЕ, чем с svn. А до того более приятную систему контроля версий, чем svn — не видел. Сказал свое ИМХО, а теперь кидайте в меня подушками!

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


98 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

День добрый! Стал потихонечку осваивать Bazaar. Запускаю его как сервис, чтобы работать по протоколу bzr (bzr://host/repo). Всё получилось, остался не решённый вопрос, как можно задать логин/пароль для разных пользователей, чтобы кто попало не мог подключиться как для внесения изменений, так и для просмотра.

Тогда уж лучше bialix’у статьи писать. Думаю, лучше него в ближайших окрестностях систему никто не знает

2 Андрей Светлов: хотелось бы увидеть еще материалы на эту тему, интересно.

индузные программисты не любят/не умеют программировать на Питоне? Умение программировать на Питоне здесь не важно, если есть API для работы с системой контроля. Главное чтобы его можно было перенести на нужную платформу, т.е. иметь заголовочный файл. А дальше кому нужно, те напишут всё необходимое.

Мне кажется Вы чего-то недопонимаете. Bazaar написан на языке программирования Python. Заголовочные файлы — это из языков C/C++. Всё API для работы с потрохами Bazaar — тоже все питоновское. Для того чтобы было все так просто как Вы хотите, а именно цитирую: «Главное чтобы его можно было перенести на нужную платформу, т.е. иметь заголовочный файл», нужно чтобы кто-то написал сишную обвертку вокруг питоновского API.Учитывая, что API Базара хоть и сохраняет обратную совместимость в течение нескольких версий, однако все таки меняется довольно часто и новые версии выходят каждые месяц-полтора, а стабильность API установлена в не менее чем 3 релиза, т.е. примерно каждые 2−3 месяца такую обвертку придется обновлять.Поэтому если такая обвертка не будет поддерживаться основными разработчиками, то она очень быстро устареет и перестанет работать.Это не оправдание почему нет, а объяснение почему нет. В опенсорс если никто не платит за какую-то фичу деньги, то она появляется только если у кого-то способного ее написать появляется острая нужда в ней. Поскольку Вы не платите за продукт ничего, то откровенно говоря ждать у моря погоды практически бесполезно. Если разработчик не имеет острой нужды в фиче, а пользователь не готов стимулировать фичу рублем, то в опенсорс мире это означает, что фичи не будет. Sorry.Вы можете оформить баг-репорт по этому вопросу: https://launchpad.net/bzr/+fil...Возможно это как-то простимулирует людей.

Или просто они выбирают Меркуриал вместо Базара?

Думаю, что выбор системы контроля не зависит от ориентированности платформы разработки, а исключительно от удобства и скорости работы.

индузные программисты не любят/не умеют программировать на Питоне?

Умение программировать на Питоне здесь не важно, если есть API для работы с системой контроля. Главное чтобы его можно было перенести на нужную платформу, т.е. иметь заголовочный файл. А дальше кому нужно, те напишут всё необходимое.

SVN — это лидер по числу использований и стандарт де-факто. С ним тягаться сложно, хотя бы потому что он старше и имел больше времени на развитие.У bzr хромает поддержка винды, поскольку я не вижу появления заинтересованных хакеров из мира Windows. Говорит ли это о том, что виндузные программисты не любят/не умеют программировать на Питоне? Или просто они выбирают Меркуриал вместо Базара? Я не знаю.

К сожалению нужной интеграции нет.

Большинство bzr-хакеров из мира Линукса, так что вот.

Ну и что??? SVN тоже OpenSource, однако же есть куча всего, в том числе и универсальный плагин для всех сред поддерживающих SCC API.

Эта страничка содержит информацию по известным или желаемым интеграциям: http://bazaar-vcs.org/IDEInteg...Если для Вашей IDE ничего нет, значит никто этого пока не написал. Поскольку это OpenSource, то ждать у моря погоды не стоит: или надо написать самому или заплатить кому-то денег. Тем более что PowerBuilder — это только для Windows и он имеет коммерческую лицензию. Большинство bzr-хакеров из мира Линукса, так что вот.

А как насчёт плагина для подключения к средам разработки. Интересует PowerBuilder?

нормальный черрипик теоретически известен. все 4 упоминавшиеся системы (monotone, git, hg, bzr) используют DAG для работы с историей. DAG имеет принципиальное слабое место — это cherrypicks. Если он и эмулируется в git, то весьма остроумным способом. Мне интересно было бы узнать как, но не настолько интересно, чтобы читать git-исходники. Если можете рассказать как оно работает внутри (не как снаружи все шоколадно — это неинетересно) был бы очень признателен. Это на самом деле очень интересная и сложная проблема.Черрипик с сохранением ссылок на историю сегодня в Базаре не реализован. В принципе он может быть реализован, и даже известно как, но пока что нет. Так что я не стану сильно возражать против формулировки, что его нет вообще. Он есть, но позволяет только подтягивать изменения в файлах, без ссылок на кусочки истории. А без истории он слабо интересен. Иногда нужен, но в целом неинтересен.У Базара куча недостатков, однако в других системах тоже есть недостатки. Просто там другой набор недостатков.Однако это не умаляет достоинств гита. Или того же меркуриала. Однако это не значит, что у них нет недостатков.Однако, несмотря на то, что все три системы open-source, между ними идет скрытая война. Война за пользователей прежде всего. По косвенным оценкам в линукс сообществе лидирует гит, там где сильно хотят скорость и поддержку винды — меркуриал. Там где люди невольны или вольны выбирать Базар — используют его. Те, кто его используют по собственному выбору, представьте себе очень довольны. По моим прикидкам пользователи децентрализованных систем распределены по следующим группам (конечно я не аналитик, просто сложилось такое мнение): гит используют 40−50%, меркуриал 25−30%, около 15−20% пользователей базара. Меньше 5−10% остается на даркс (он все еще популярен, хотя его звезда считай что закатилась из-за до сих пор неполеченного бага с конфликтами при объединениях) и прочих типа monotone. Если у вас при суммировании получилось больше 100% — это потому что есть группа смешанных пользователей, которые используют несколько систем одновременно.

> внутри живут уникальные id [...] можно юзать revid вместо revnoПодозревал, но не знал, спасибо.> какое отношение здесь имеет черрипик — я не понимаю.Почему-то в системе, где бранчи как эээ... аналогия убрана, но в общем не в одном репозитории, а разбросаны по окрестностям-каталогам (я в курсе про init-repo, выглядит не менее ужасающим костылём, чем окрестности man bzr в районе описания этой опции) — нормального cherry-pick тем же вышеупомянутым каноникаловцам неизвестно. Поэтому просили оформить в идеале каждое изменение (!) отдельным бранчем (!). В итоге порешали, как сделать всё-таки одним и шоб им втянуть сразу, но нервов это забрало на порядок больше, чем могло, а по времени задержка получилась всего-то в неделю (с учётов переделок и пересинхронизаций).Потом задумчиво дёргал ягодки в git и недоумевал — ну почему, зачем люди так над собой измываются? Оно, конечно, после cvs всё морковка послаще, но рядом ведь ананасы растут! Или это винда в популярности мазохизма как концепции опять виновата?:) Ну так выкидывайте, пока не поздно. Уже ж началось.

понятно. однако следует знать что внутри bzr номера не используются. внутри живут уникальные id, как в остальных версиях (в git и hg — это sha1-хэши, как вы знаете). если есть желание, можно юзать revid вместо revno.какое отношение здесь имеет черрипик — я не понимаю.

Ник bialix, вообще-то там рядом же и вздохи насчёт git были. Часть разработчиков работает в Canonical и они в заложниках у launchpad, который в заложниках у bzr, такая вот фигня.Мне-то за них и за коллегу, которому с этим работать, скорее досадно. Жалко, когда люди мучаются, тем более если на дурняк.Ровно потому и решил написать сюда поправочку к «вивату». Простите, если чем огорчил — ничего личного.PS: вот как придумают с этими дебильными ревизиями нормальный cherry-pick — так вернёмся к разговору о том, нужны ли они тут вообще или при distributed только добавляют шума в голове — тебе кажется, что ревизия такая-то, ан это не самодостаточная информация — нужно ещё в голове держать конкретный бранч. Два критично связанных куска информации вместо одного неделимого, как commit id в гите. Где, как ни странно, и черрипик — пальчики оближешь: просто как двери и пашет как трактор.

Александр Соловьев: какую вам дать ссылку на отсечение? Может ссылку на исходники Меркуриала? Или на набор его команд. В частности на команды copy или rename? или может вспомнить, что в Меркуриале есть явный remove? Могу дать ссылку на исходники Базара, чтобы вы сами сравнили из чего состоит ревизия в Меркуриале и Базаре и рассказали в чем разница, когда и тот и другой при фиксации сохраняет состояние дерева в конкретный момент времени, а не изменения относительного последней фиксации. А?

> Кстати, по Вашей ссылке хочу заявитьВ общем, предлагаю пойти и почитать про дизайн меркуриала для просвещения. Hg и git оба основаны на идеях из monotone, оба трекают контент.

> Кстати, по Вашей ссылке хочу заявить, что утверждение Aristotle Pagaltzis о том, что hg «track the content» не соответствует действительности. Контент отслеживает только git. Остальные идут обычным путем метаданных.Даёте ссылку на отсечение?

товарыш Шыгорын:, а спрашывается нах... матерым разработчикам форкать bzr-ng если есть такие замечательные гит и hg? Нафига пользоваться таким вот безобразием, цитирую Вас же: «тормознутая кривая глючная черезодноместопереписываемая штука»? Кстати, по Вашей ссылке хочу заявить, что утверждение Aristotle Pagaltzis о том, что hg «track the content» не соответствует действительности. Контент отслеживает только git. Остальные идут обычным путем метаданных.

PS: ещё про DSCM (с акцентом на git): http://plasmasturm.org/log/487/ — вторая половина описывает удобство даже при локальном использовании.PPS: bzr — тормознутая кривая глючная черезодноместопереписываемая штука с таким же форматом репозитория. Это ж надо — делать DSCM и бранчи по отдельным каталогам раскладывать с совмещением в один репо через /dev/arse: — (Вчера на #ltsp матёрые разработчики грустили и думали, а не форкнуть ли bzr-ng-ng. (кто сталкивался или читал man bzr около описания init-repo, тот поймёт)

> знаєте, у мене різний софт на різних операціях та за різних умов> із різною швидкістю працюєОто новина 8-) Щодо швидкості — спробуйте запхати linux kernel з історією ну хай від 2.6.0 у e.g. svn та попрацювати. Мене git ще досі не гальмував, хіба що канали...> сподіваюсь, вам ніколи не доведеться розробляти софт> для повітряної подушки в машині...Цим успішно займався колега з сусідньої кімнати (результати їхньої роботи багатьом людям життя вже зберегли, btw) —, а мені вистачає своїх лінуксових термінальних серверів; -) Сподіваюсь, мені ніколи не доведеться користуватися Вашим софтом. (цікаво, хто як це сприйме?:)

SC говорит: 8.12.2007 в 20: 31> Пані SC, виступати на семінарі, та мати досконале уявлення про розподілені> системи керування версіями — це дуже різні речі.Ну, це безумовно:) Втім, з деяких семінарів, та ще на згадану Вами тему, взашию виженуть, якщо побачать недостатній рівень підготовки доповідача.> Усі Ваші коментарі говорять> лише про те, що Ви й гадки не маєте про що говорите.Аргументуйте, шановний (а)! Прошу Вас!:)

Аргументировать я буду по-русски, уж простите. Потому что здесь запас украинских терминов у меня заканчивается.

Втім, якщо немає потреби у дистрибутивному контролі версій, то немає особливого сенсу на нього переходити. Бо він буде повільнішим і ризик галудження вищий. Потім мерджити зайвий раз, навіть якщо не важко, все одно влом.

Тот, кто боится расхождения веток — тот сразу выдает в себе давнего пользователя svn, ибо только в этой системе люди боятся веток и последующего объединения (причем если видна перспектива неоднократного объединения). Ибо есть такое понятие как merge tracking — т.е. отслеживание версий, которые уже были объединены между собой. svn обещает поддержку merge tracking с версии 1.5. Только обещает она давно, а релиза этой версии пока не видать.Видите ли, пани SC, основой распределенных систем является прежде всего упор на то, что ветки нужно объединять много и часто. Поэтому они просто обязаны делать это на отлично. Иначе ими никто не будет пользоваться.Все ваши наезды по поводу скорости — по крайней мере не понятны большинству здесь присутствующих, потому что вы приводите какие-то абстрактные примеры и оперируете какими-то ложными понятиями. Поэтому пока что вы не сказали ничего убедительного. Набор слов. Есть такое понятие как бенчмарки — специальные тесты для объективного измерения производителности. Надеюсь слышали, раз на семинарах выступали. Приведите пожалуйста конкретные результаты бенчмарков для конкретных случаев с указанием версий сравниваемых систем.

А Ви добре розумієтесь на архітектурі дистр. контролів версій?

Если под словом “добре” понимать хорошо, то — да, я хорошо разбираюсь в архитектуре распределеных систем управлениями версиями. Просто когда больше 2х лет учавствуеш в разработке одной из таких систем, и активно интересуешься данной темой, то начинаешь разбираться. Только я — практик, а не теоретик. Если Вам нужна теория — начните с сайта http://revctrl.org/FrontPage

Я, чесно, добре знаю архітектуру лише однієї із таких систем.

Какой именно? Опять какие-то туманные намеки. Будьте конкретны. Пока что Вы усиленно всем пускаете пыль в глаза, пытаясь доказать свою крутизну. Я тоже на семинаре выступал по поводу распределенных систем и распределенной разработки. Ну и что?

Але до того ж я знаю певні риси та вимоги до дистрибутивних систем в цілому. Оскільки такі вимоги вищі, аніж до централізованих систем, то очікувати, що рішення будуть легшими, щонаймешне наївно.

“Риси та вимоги” — собственно все определяется одним единственным словом: децентрализованные системы должны работать без сервера. Фсё. Про какие именно решения речь — не понятно. Чем вам сервер кажется проще и быстрее — не понятно. Ибо сервер обслуживающий скажем 100 запросов ста разработчиков одновременно — по любому проиграет локальной машине аналогичной мощности, которая обслуживает 1 запрос одного разработчика за раз. О чем вообще речь? Кого вы считаете наивным? Линуса Торвальдса, например? Я надеюсь Вы внимательно ознакомились с его выступлением в Гугле “Linus Torvalds on Git” (есть видео, есть текстовая расшифровка)? Если еще не знакомились, то обратите внимания, как часто Линус говорит, что ему нужна была скорость и он ее получил. А также обратите внимание на то, что он рассказывает про объедиения. Его пламенное выступление фактически очень слабо завязано на специфику системы git, а является очень яркой иллюстрацией положения дел для всего современного рынка распределенных систем (я говорю о тройке лидеров: Git, Mercurial, Bazaar).

сподіваюсь, вам ніколи не доведеться розробляти софт для повітряної подушки в машині...

Опять пытаетесь кичиться своей крутизной. Я — разработчик встраиваемых систем. Что такое реальное время — знаю не понаслышке. Я надеюсь Вам никогда не придется разрабатывать ПО для контроллера управления инжекторным двигателем автомобиля.

І не моя провина, що у цьому порівнянні базар не згадали, просто це одне із найбільш багатосторонніх та систематизованих порівнянь, яке я бачила.

Все эти сравнения или куплены или заказаны или всегда остается риск необъективности автора. Я не знаю, какие выводы вы пытаетесь сделать по этому сравнению, потому что все сравнения — это просто маркетологическая макулатура. Если вы пытаетесь оценить некую мифическую скорость по такому сравнения — о, боже! — то дальше убеждать мне вас нечем. Покажите результаты бенчмарков, тогда будем сравнивать скорость.

Мене просто вражають необ’єктивні статті та відгуки захоплень про нові дистрибутивні SCM. Вони, звичайно, хороші, але не панацея!

Фредерик Брукс больше 30 лет назад доказал, что панацеи, как и серебрянной пули, не существует. Тот кто не видит недостатков в используемых инструментах — тот просто плохо с ними знаком.Если говорить про систему Базар — то она поддерживает 2 типа работы: полностью распределенная работа и работа в централизованном режиме, с центральным сервером, которую Вы так высоко цените. Ну и какие из этого можно сделать выводы? А из рассуждений Бена Сассмана о том, что в svn 2.0 появится расширенная поддержка работы в оффлайн и svn станет ближе к распределенной модели работы — какие из этого можно сделать выводы? Включая то, что они собираются передрать некоторые архитектурные решения из Mercurial? А какие можно сделать выводы из того, что многие крупные опен-сурс проекты выбрали Mercurial в качестве системы управления версиями? Например, проект Мозилла — не в последнюю очередь выбирал систему исходя из скорости работы. Вы представляете объем исходников в проекте Мозилла? Он выражается такой цифрой: больше 50 тысяч файлов в 5 тысячах каталогов. Скорость здесь ой как нужна.

Якщо хтось переконаний, що конкретна софтяра фуричить швидше, то де Ваші аргументи? Статистичні аналізи по конкретних операціях — віддалених комітах, апдейтах тощо. Наводьте і аргументовуйте!

Пока что это был именно Ваш наезд на скорость. Те, кто активно использует системы и так знают всё про скорость работы. Это Вы должны приводить цифры. Вы же на семинаре выступали: -) Почему Вы думаете, что мы будем оправдываться? Нам не надо оправдываться. Это Вы хотите доказать, что мы не правы — Вы и доказывайте.

>> середньостатистично DVCS є повільнішою за СVCS> Ну то й не їжте середньостатистичну ковбасу: -) Дивні люди — роблять статистику > там, де або зустріну динозавра (робить швидко), або ні (гальмує).мабуть, ми з різних планет... знаєте, у мене різний софт на різних операціях та за різних умов із різною швидкістю працює:) і далеко не завжди це можна виміряти «на око».сподіваюсь, вам ніколи не доведеться розробляти софт для повітряної подушки в машині...> Повторюся — вищезгаданий git навіть як локальний однокористувацький інструмент > контролю версій для мене має купу переваг над cvs, починаючи від git > mv/checkout -b та далі у бік можливості push’нути додому — як для бекапу, так і > на випадок, коли дома офлайн та можна ще щось там наколупати (в > однокористувацькому, знов-таки, режимі).де ви бачили, щоб я рекламувала cvs як кращий за інші контроль версій???:) та йому ж > 20 років!))

> > Ось гарне порівняння різних SCM: > > http://better-scm.berlios.de/c... > Чим воно краще? Там Bazaar навіть не згадується. Це що, так тепер роблять > об’єктивні порівняння, просто вилучаючі конкурентів з списку? bialix, мисліть ширше! Я не упереджена ані до базару, ані до дистр. контролю версій. І не моя провина, що у цьому порівнянні базар не згадали, просто це одне із найбільш багатосторонніх та систематизованих порівнянь, яке я бачила.Мене просто вражають необ’єктивні статті та відгуки захоплень про нові дистрибутивні SCM. Вони, звичайно, хороші, але не панацея! А дехто саме як панацею їх і розцінює. Це занадто суб’єктивно. Дистрибутивний софт хороший там, де потрібна дистрибутивність, а там де вона не обов’язкова, знайдеться швидше працюючий спеціалізований софт.Якщо хтось переконаний, що конкретна софтяра фуричить швидше, то де Ваші аргументи? Статистичні аналізи по конкретних операціях — віддалених комітах, апдейтах тощо. Наводьте і аргументовуйте!

> Пані SC, виступати на семінарі, та мати досконале уявлення про розподілені > системи керування версіями — це дуже різні речі. Ну, це безумовно:) Втім, з деяких семінарів, та ще на згадану Вами тему, взашию виженуть, якщо побачать недостатній рівень підготовки доповідача.> Усі Ваші коментарі говорять > лише про те, що Ви й гадки не маєте про що говорите.Аргументуйте, шановний (а)! Прошу Вас!:) А Ви добре розумієтесь на архітектурі дистр. контролів версій? Я, чесно, добре знаю архітектуру лише однієї із таких систем. Але до того ж я знаю певні риси та вимоги до дистрибутивних систем в цілому. Оскільки такі вимоги вищі, аніж до централізованих систем, то очікувати, що рішення будуть легшими, щонаймешне наївно.

SC говорит: 8.12.2007 в 00: 24 ...Я на семінарі по темі DVCS виступала:)

Пані SC, виступати на семінарі, та мати досконале уявлення про розподілені системи керування версіями — це дуже різні речі. Усі Ваші коментарі говорять лише про те, що Ви й гадки не маєте про що говорите.

# SC говорит: 7.12.2007 в 22: 58Ось гарне порівняння різних SCM: http://better-scm.berlios.de/c...

Чим воно краще? Там Bazaar навіть не згадується. Це що, так тепер роблять об’єктивні порівняння, просто вилучаючі конкурентів з списку?

> середньостатистично DVCS є повільнішою за СVCSНу то й не їжте середньостатистичну ковбасу: -) Дивні люди — роблять статистику там, де або зустріну динозавра (робить швидко), або ні (гальмує).Повторюся — вищезгаданий git навіть як локальний однокористувацький інструмент контролю версій для мене має купу переваг над cvs, починаючи від git mv/checkout -b та далі у бік можливості push’нути додому — як для бекапу, так і на випадок, коли дома офлайн та можна ще щось там наколупати (в однокористувацькому, знов-таки, режимі).А про мержи — є інструменти, де це аврал, а є — де це стиль роботи й норма, тому цей процес якомога автоматизовано та полегшено. Висновки залишаються читачеві: -)

> ну я не прихильниця міряти «на глазок» та «по общим ощущениям»:) Ну я тоже, но время замерять лень.: -) > Може, у вас свн криво до апача прикрученийВ каком смысле?;) > чи https маєте на увазіhttps — это вообще непотребство, а не скорость.; -) > Я не «наїжджаю» на DCVS, просто наголошую на тому, що в них є своя ніша, свої переваги та недоліки.Логично. Но я просто говорю о том, что недостатка скорости не видно. Как-то оно вполне так живенько работает.>, а потім кинетеся синхронізуватися і мерджити гілку, що виникла, — замахаєтесьТак в svn то же самое. Я просто реже коммичу, и точно так же есть вероятность напороться на мерж. Не так это и напряжно.: -)

> делаю десяток-два коммитов локально, а потом закидываю их на сервер. И это> выходит быстрее, продуктивнее и заметно менее опасно в плане поломки чьего-то > кода, нежели работа с свн.Знаєте, я би сказала, що саме у такий спосіб небезпечно користуватися... Принаймні якщо ви працюєте не сам, а в команді. Бо ви так зробите пару десятків локальних комітів, і ваш колега аналогічно, а потім кинетеся синхронізуватися і мерджити гілку, що виникла, — замахаєтесь: (

Шановний Александр Соловьёв, ну я не прихильниця міряти «на глазок» та «по общим ощущениям»:) Може, у вас свн криво до апача прикручений... чи https маєте на увазі (там свн донедавна тормозив). Це все частинні випадки. А ж говорю про загальні тенденції, зумовлені архітектурою цих софтяр. Про це ж свідчать і бенчмарки.Я не «наїжджаю» на DCVS, просто наголошую на тому, що в них є своя ніша, свої переваги та недоліки.

> Alexander Solovyov, а які Ви маєте на увазі операції, коли говорите про продуктивність? Общие ощущения. Я делаю десяток-два коммитов локально, а потом закидываю их на сервер. И это выходит быстрее, продуктивнее и заметно менее опасно в плане поломки чьего-то кода, нежели работа с свн.> Уявіть собі, навіть у порівянні із CVS по багатьох операціях програє.Не знаю, что за специализированная DCVS, но я не вижу медленности меркуриал при push’е или pull’е. Я вижу только медленность svn. Я не проводил никаких тестирований, никаких исследований, но общее ощущение — заметно быстрее. Ну раз так в несколько на глазок. Один и тот же проект стянулся из mercurial’а быстрее, чем из svn -, но сервера разные (хоть и одинаково далеко от меня находятся практически), потому тут утверждать нечего.Но что это не медленно — это 100%.

Alexander Solovyov, а які Ви маєте на увазі операції, коли говорите про продуктивність? Локальні операції, безсумнівно, будуть у DVCS швидшими. А щодо не-локальних — ой не погоджуюся. Аж цікаво стало, чому у вас svn повільно працює... Будь-яка розподілена система має переваги у надійності над централізованою. Але й у централізованої є переваги: немає додаткових вимог щодо синхронізації, відстежування цілісності репозиторіїв (окрім свого), а отже вона є швидшою (ми ж не говоримо про розподілені обчислення, так?).Тобто я хочу сказати, що середньостатистично DVCS є повільнішою за СVCS. Я на семінарі по темі DVCS виступала:) Якщо не вірите мені, ось почитайте документик про спеціалізовану мініатюрну DVCS на Distr. Hash Table — Pastwatch. Там у кінці є бенчмарки, порівняння із CVS. Уявіть собі, навіть у порівянні із CVS по багатьох операціях програє.http://pdos.csail.mit.edu/pape...

> Бо він буде повільнішимКакие-то ущербные представления о DVCS у тебя. Я перешёл везде на меркуриал там, где мог это сделать, просто потому, что он намного быстрее svn работает. Просто на порядки. И выше я жаловался на производительность базара, который тоже работает быстрее сабвершена.Попробуй устриц, а уж потом ругай их.

Втім, якщо немає потреби у дистрибутивному контролі версій, то немає особливого сенсу на нього переходити. Бо він буде повільнішим і ризик галудження вищий. Потім мерджити зайвий раз, навіть якщо не важко, все одно влом.

Найкращі відгуки як про дистрибутивний контроль версій я чула про darcs, збираюся спробувати.

Ще є такий distributed version control: monotone.Хто-небудь пробував?

jaguar говорит: 7.11.2007 в 19: 06Я наверное не очень вьехал в тему. Кто мне обьяснит, как распределнный репозиторий потом мержит хистори двух веток, которые разрабтывались какое-то время отдельно друг от друга, без синхронизации? Ну пример: я анбиндился от репозитория, сделал 10-ток багофиксов (ка каждый по 1−2 комита у себя). В то же время пара дургих разработчиков делала тоже по 10−20 комитов отбинденые от остальных. И естественно каждый мой комит мог зацепить те же строчки, что и у моих товарищей. По-моему потом с ними синхронизироваться будет уже не возможно, т.к. чтобы в итоге была полная хистори изменений и можно было посмотреть, кто, что в какой момент и для чего изменял.

Все не так, все горяздо проще.1) В bzr нет понятия «синхронизироваться». Есть понятие — «объединиться» (merge). При объединении две ветки пытаются соединить в одну точку. Если в разных ветках были внесены исправления в одну и ту же строку в каком-то файле, то вы получите конфликт. Однако это не влияет на процесс объединения. Конфликты вы разрешаете либо ручками в своем любимом редакторе, либо при помощи спец.программ типа WinMerge и т.п.2) Само по себе объединение не создает новой версии или записи в истории. После объединения новую версию исходников нужно фиксировать как обычно. После этого в логе вы будете видеть все версии (revision) из другой ветки, которые вы объединили со своими.3) Для того, чтобы посмотреть кто когда и что менял имеется команда annotate, которая для каждой строчки файла показывает номер последней ревизии, в которой были внесены исправления, а также кто и когда.

Потому, что их нужно периодически синхронизировать и когда я смотрю хитори основной ветки и вижу там комит с коментарием «merged with branch» то я могу пойти и посмотреть лог того бранча.

В bzr вам не надо куда-то идти. Это видно сразу.

Во первых, когда вы делаете ветку в svn — это действительно серьезная причина. Новая экспериментальная версия или серьезный багфикс.В базаре ветка делается для того, чтобы вы сделали свои изменения. Личные.Другой разработчик сделал то же.Как потом быть? Да так же, как и в svn, только удобнее.Можно мержить параллельные ветки и, добившись совместной работы, выложить это в trunk.Или еще куда нибудь (наша_совместно_собранная_ветка.dev) Можно попытаться запостить свое первым — привет, svn, кто последний, тот и латка (в смысле именно он разбирается с конфликтами). У нас на работе это нередко превращалось игру.Если все изрядно запутано — много разработчиков, они не сидят рядом, каждый ведет свою ветку — то тоже все видно. Кто когда и как менял.И, самое главное, что я увидел — свобода.Желаешь работать «как в svn» — работай. Желаешь сделать ветку — делай. Она не отразится в главном репозитарии. Если хочешь ее засветить — свети. Склеивай с другими. Работай локально — и потом склеивай.Можно базар рассматривать как «svn с большими степенями свободы», но этим он не исчерпывается.Централизованный svn — можно так и на базаре. А можно и иначе (причем для каждого разработчика).Кому что нравится. Осваивать новое можно в процессе использования.Базар дает больше гибкости, на мой взгляд. Не накладывая ограничений.

Вот именно, что просто намного лучше, чем в svn всё сделано. Ты видишь все чейнджсеты, более того, есть программы, которые не напрягаясь рисуют график что и когда с кем было смержено в данном текущем репозитории.

В svn ветки потому и заводятся по серьезным причинам. Потому, что их нужно периодически синхронизировать и когда я смотрю хитори основной ветки и вижу там комит с коментарием «merged with branch» то я могу пойти и посмотреть лог того бранча. Но представьте себе сколько будет проблем посмотреть номарльно лог, когда у нас практически весь хистори основной ветки будет состоять из комитов-синхронизаций? Хотя может и не так проблемно, как кажется. Я конечно не пробовал.

Я наверное не очень вьехал в тему. Кто мне обьяснит, как распределнный репозиторий потом мержит хистори двух веток, которые разрабтывались какое-то время отдельно друг от друга, без синхронизации? Ну пример: я анбиндился от репозитория, сделал 10-ток багофиксов (ка каждый по 1−2 комита у себя). В то же время пара дургих разработчиков делала тоже по 10−20 комитов отбинденые от остальных. И естественно каждый мой комит мог зацепить те же строчки, что и у моих товарищей. По-моему потом с ними синхронизироваться будет уже не возможно, т.к. чтобы в итоге была полная хистори изменений и можно было посмотреть, кто, что в какой момент и для чего изменял. Я так понимаю либо история изменений теряется и все ченжесы мержаться одним комитом? Мне кажется, что все таки централизованная svn лучше именно тем, что имеется четкая хистори всех изменений. И я точно помню, что вот эту строчку я менял такого-то числа, когда фиксил вот этот баг.

открыл группу ru_bzr: http://groups.google.com/group...

да, размер инсталлятора меня самого беспокоит. к сожалению там не так просто уменьшить, хотя есть что выкинуть.

> Замечу, что скомпилированный bzr.exe имеет меньшее время старта, Упс. У меня просто дома трафик, потому качал что поменьше. Буду знать.:) > Если Вас не затруднит провести свое сравнение через месяц-дваНе затруднит, работы-то не много для этого надо.:) Я надеюсь, что ещё найду время насетапить базар на сервер, чтоб проверить, как оно там работает. piranha AT piranha.org.uaP.S. Не, я таки напишу Максу по поводу маркдауна.:)

Александр — спасибо за цифры. Я перешлю их в наш список рассылки.Кстати, видно что вы тестировали скомпилированный hg.exe и чисто питоновский bzr.Замечу, что скомпилированный bzr.exe имеет меньшее время старта, поэтому при запусках его в ваших тестах цифры для bzr были бы меньше на 100−200 мс. Это конечно крохи, но все таки факт имеет место быть.Формат knitpack пока еще экспериментальный, не все еще части тщательно оттюнингованы. Если Вас не затруднит провести свое сравнение через месяц-два, я был бы рад вас уведомить о выходе новой версии, когда этот формат станет основным.

Эмм... Тег code как-то плохо сработал.: (Поддержка маркдауна какого-нибудь была бы неплоха...

Однако! Осталось попробовать его серверную часть, и действительно можно будет сказать «Виват, Бозар! » (это не ошибка, это Фоллаут;)) Вот батник, которым тестировал:

@echo offcd bzrcxtimeit C:Python25python.exe C:Python25Scriptsbzr init --knitpack-experimental .timeit C:Python25python.exe C:Python25Scriptsbzr add -qtimeit C:Python25python.exe C:Python25Scriptsbzr ci -q -m "initial"cd ..timeit C:Python25python.exe C:Python25Scriptsbzr clone -q bzrcx bzr1timeit C:Python25python.exe C:Python25Scriptsbzr clone -q bzrcx bzr2timeit C:Python25python.exe C:Python25Scriptsbzr clone -q bzrcx bzr3cd hgcxtimeit hg init .timeit hg add -qtimeit hg ci -q -m "initial"cd ..timeit hg clone -q hgcx hg1timeit hg clone -q hgcx hg2timeit hg clone -q hgcx hg3

Вот его вывод (побил на части — добавление/клонирование/добавление/клонирование):

time: 0.891 time: 0.937 time: 1.313 time: 2.344 time: 2.031 time: 2.062 time: 0.282 time: 0.422 time: 1.531 time: 1.937 time: 1.453 time: 1.593

Понятное дело, что тестирование не слишком убойное: D, но меня в принципе не волновала абсолютная производительность. Можно сказать, что они действительно сделали хорошую работу. Сделали б полгода назад — в сторону меркуриала и не взглянул бы.: DИтак, на очереди сетевая версия. Когда доберусь — не знаю.: (

> Она напечатает время выполнения программы в секундах. Пойдет? То что надо, просто аналог time из никсов. Вечерком замерю всё.:) > Из тех отзывов, что я читал в сети — скоростью не блещет.Зачем отзывы, она реально не блещет.;)

monotone: из поколения первых распределенных систем. Использует sqlite для хранения репозитория. Много внимания уделяется интегральной целостности репозитория — поэтому она насквозь пронизана sha1-хешами кругом. Даже номера ревизий — и те формируются из хешей. Этим она мне не понравилась. Я поставил, почитал доку — как-то все запутанно и накручено. Из тех отзывов, что я читал в сети — скоростью не блещет.

2Alexander Solovyov: Андрей Возница из Львова подсказал другой метод измерения времени, через дополнительную программку. Вот собственно результат: http://www.bialix.com/bzr-win3...Киньте ее в любую папку, которая у вас в путях, потом просто пишите timeit перед вызовом bzr/hg, например: timeit bzr —no-plugins initи т.п.Она напечатает время выполнения программы в секундах. Пойдет?

А на рахунок monotone, Хто що може сказати?

windows bias — это только у меня. Практически 99% разработчиков используют Linux, четверка главных разрабов вообще получает зарплату в Canonical Ltd.По поводу kdiff3 и прочего: портированный на windows diff3 всегда сохраняет выходной файл с CRLF концовками, даже если исходные файлы имели LF-only. kdiff3 тоже я так понимаю имеет эту проблему — видел по этому поводу открытый баг в трекере Mercurial. Так что встроенная merge — это очень жЫрный плюс для меня

> Юзер также может настраивать свои aliasДа, это отличная штука. Мне её не хватает в меркуриале.;) > На винде такие фокусы стоят много нервов. А винда для меня — главная платформа, хотя много пишу под Линукс; -) Я тоже сижу на винде, но проблем не испытал, честно говоря. Поставил kdiff3, написал строчку в конфиг — и всё работает.> Ну вроде чо-то с той стороны недавно доносилось, Я слежу за гитом, пока никаких подвижек. Т.е. его-то запускают, но он тормознутый до ужаса.> почитал про 250/500/1000 файлов — стало грустно:) ну у меня есть проект намного больший, но он под сабвершеном и не в моих силах это изменить.;) Хотя стараюсь. На тему больших проектов — я пытался качать мозиллу — она медленнее линухового ядра ползёт.:) > хотя windows bias даёт свои перекосы — как же вам там, бедным, тяжко с инструментарием...100%. Но так как отказаться не могу, то — mercurial.:) > (работает под TurboGears) Это плохо.> Тут написано, что интегрируется: http://doc.bazaar-vcs.org/bzr...Хо! Научили, вроде. Надо попробовать. Делать push через ssh я себе не могу позволить — не могу заводить на каждого коммиттера аккаунт на сервере.

2 Родион Быков: > На месте руководителя проекта фиг бы я отдал контроль над главным репозиторием.Это логика CVS, здесь она неприменима (нет такого идиотского ограничения, как технически главный репо). Почитайте первую ссылку в первом комментарии:) 2 Alexander Solovyov: > Так что меркуриал — тхебест. Пока гит на винде не заработает нормально.Ну вроде чо-то с той стороны недавно доносилось, хотя для меня было радостней услышать про оптимизации в gitk, которые позволяют использовать его для всей истории всего linux kernel (почитал про 250/500/1000 файлов — стало грустно, git на средних-то проектах шуршит очень быстро, а большими не давится).2 Caujka: > И 1 человеческий язык общения.Это типа «слава роботам» было?...sigh2 bialix: Спасибо за отзывы, статью по сумме было бы интересно почитать (хотя windows bias даёт свои перекосы — как же вам там, бедным, тяжко с инструментарием...) >> unix-way:) > На винде такие фокусы стоят много нервов.Ну так это проблемы винды, простите. Вон сколько времени угробили на поиск аналога банального time (1)...Кстати по поводу мержей — git уже научили mergetool и звать при возможности meld, tkdiff, vimdiff или ещё полдюжины всякого-разного на помощь;)

Теплый-холодный кеш (не знал, кстати, что они так зовутся) — известная беда.Я привык оценивать свои ощущения по «теплому». Ведь я системой пользуюсь постоянно, а не от случая к случаю.По поводу сокращений: не спорю, настройка их — фича очень мощная.В svn проблема алиасов решается так: svn help... blame (praise, annotate, ann) ...У вас бы могло быть annotate (ann, blame, praise) Если возможно, неплохо бы включить и настройки пользователя. Но это уже не важно.По опыту — если человек такое видит — начинает использовать. Если нужно долго читать — не читает, пока случайно не наткнется. А вещь востребованная. Просто вы этого не видите, т.к. досконально знаете систему (по себе сужу). Не всегда вычитывается manual «от и до». Гораздо чаще — «до состояния способности работать с системой». Потом уже набирается нужный опыт — если задача заставляет лезть опять в manual.А еще. Если алиасы можно настраивать — то почему бы не упомянуть последней строкой ссылку на http://doc.bazaar-vcs.org/bzr...? Хотя, может быть, последнее — лишнее.Мелочь, как я уже говорил. Мне — не мешает. Но было бы приятно.

> А также меня полностью убивает отсутствие в нем встроенного merge — для этой цели он нуждается во внешних подпорках типа diff3.Не вижу состава преступления — я могу использовать любую навороченную прогу, а не то, что они там себе придумали на коленке. unix-way;)

На винде такие фокусы стоят много нервов. А винда для меня — главная платформа, хотя много пишу под Линукс; -) В bzr есть своя реализация 3-way merge, плюс есть возможность юзать diff3 если охота. При помощи плагинов ext-merge или difftools можно подключать сторонние мерджилки. Но меня встроеная во многом устраивает. А конфликты я со времен CVS научился править ручками в своем редакторе.

Из мелочей. В svn help тут же показываются короткие сочетания (update (up), commit (ci), checkout (co), move (mv), status (st) и т.д.)

В bzr это называются alias к команде, встроенные alias можно увидеть в развернутом help к команде, например

C:\work\Bazaar\mydev>bzr help annotatePurpose: Show the origin of each line in a file.Usage: bzr annotate FILENAMEOptions: --all Show annotations on all lines. -v, --verbose Display more information. -h, --help Show help message. -q, --quiet Only display errors and warnings. --long Show commit date in annotations. --show-ids Show internal object ids. -r ARG, --revision=ARG See "help revisionspec" for details.Description: This prints out the given file with an annotation on the left side indicating which revision, author and date introduced the change. If the origin is the same for a run of consecutive lines, it is shown only at the top, unless the --all option is given.Aliases: ann, blame, praise

В конце — видите? Иногда таких алиасов больше одного. Как прикажете их показывать? Юзер также может настраивать свои alias: http://doc.bazaar-vcs.org/bzr...Мощная фича кстати.

«Конец июня этого года/начало июля.» — это скорее всего была версия 0.17 (http://bazaar-vcs.org/news). С тех пор выпустили еще почти 4 версии (0.18, 0.90, 0.91, 0.92rc1). В каждой из которых были улучшения касаемо скорости.Однако должен заметить, что парни из команды hg оптимизировали систему для работы с «холодным» кешем, замеряли даже миллисекунды, которые тратятся на позиционирование головок жесткого диска (была такая информация; к слову сказать даже git и тот оптимизирован под теплый кэш). Поэтому у меня наблюдения такие: когда только начинаешь работать с проектом в начале дня, то заметна «задумчивость». Как только винда помогает жесткому диску своим кешем — так сразу летать начинает.: -) Плюс объем исходников в hg заметно меньше чем в bzr (я об этом говорил выше, что у bzr много фич и толстые исходники). Это косвенно влияет на start-up time питон-программы. Самая быстрая команда в bzr:

bzr rocks

.

последнем — на предыдущей работе

По поводу hgwebdir.Если речь идет об вот таком: http://selenic.com/repo/hgТо у Базара есть loggerhead: http://codebrowse.launchpad.ne... (работает под TurboGears) Делать push/pull без клиента все равно не получится, поэтому тут особого преимущества от hgwebdir я не вижу. Базар умеет делать pull с обычного http, и делать push на ftp/sftp. Впрочем у hg этот cgi-скрипт работает как некий smart-server, поэтому сравнивать с dumb server при простом доступе bzr через http несколько некорректно. В bzr есть отдельный smart-server, его нужно подымать отдельно, тогда он позволяет работать через протокол bzr://. Кстати я раньше соврал, что он не интегрируется с апачем. Тут написано, что интегрируется: http://doc.bazaar-vcs.org/bzr...В [f] cgi/mod_python/wsgi и прочей web-алхимии я не силен, поэтому на работе использую trac+bzr для просмотра текстов через web-интерфейс. Для push/pull/commit — sftp и bzr+ssh.

2bialix: Спасибо вам за хорошие ответы.Я консервативен в используемых системах облегчения жизни разработчика.Долгое время меня устраивала svn, о чем вам не раз и писал.Потом сменились внешние обстоятельства, и стало возможным поискать альтернативу — благо была одна на примете:) Эксперимент считаю удачным для себя.Буду рекомендовать друзьям и приятелям.Кстати, а что вам НЕ ПОНРАВИЛОСЬ в Базаре? На какие неудобства вы наткнулись? Крайне интересно услышать критику от весьма знакомого с системой человека.Скорость... В самом моем большом проекте было около 250 файлов. Неудобств по скорости не ощутил. Так же быстро, как и svn. Мне показалость приемлимым.Конечно, было бы интересно оценить на моем последнем проекте.Там было порядка 15 000 файлов в svn, и svn откровенно тормозила. Она тормозила заметно даже на другом проекте из 1500 файлов.Из мелочей. В svn help тут же показываются короткие сочетания (update (up), commit (ci), checkout (co), move (mv), status (st) и т.д.) В bzr это неочевидно. Понял, что оно работает — только забывшись и по привычке написав «как в svn». А поправить так легко!

Окей, давай так. Пока об ощущениях: есть проект на 163 файла, 24 ревизии в меркуриале и 1 базаре. Если делать инит без —knitpack-experimental, то базар где-то на порядок медленнее. Если с ним, то явного преимущества в скорости нету ни у того, ни у того. Проверяю на клонировании репозитория.Ещё бы проверить это дело по сети (меня меркуриал подкупил скоростью, заметно быстрее сабвершена гоняет всё), но на сервер поставить релиз кандидат не представляется возможным. Завтра постараюсь выделить время погонять между двумя компами хотя бы.Но базар ускорился. Определённо. Остался hgwebdir.

однако на моей системе сам ProcessMonitor жутко тормозит все процессы: — (Предлагаю: завтра я пересоберу bzr и hg по методу предложенному Андреем Светловым и выложу на к себе сайт.

2Александр Соловьев: Поскольку время выполнения hg тоже интересно для сравнения, то наверное целеообразно использовать Process Monitor http://www.microsoft.com/techn...В фильтр добавьте ProcessStart и ProcessExit

Вообще-то история лично у меня вызывает те же ощущения, что и переползания с CVS на SVN.

А у вас standalone installer? если нет — то открыть файл bzr (у меня он в c:/python25/scripts) и в начале написатьimport sysimport timet1 = time.time () def exitfunc (): print ’eplased time: ’, time.time () -t1, ’secs’import atexitatexit.register (exitfunc) Если очень нужно — можно и собрать версию с поправкой, чтобы переслать вам.

Чем можно засечь время исполнения под виндой?;)

> Или хотя бы приблизительно когда это было.Конец июня этого года/начало июля. Сейчас скачаю новый, посмотрю.> А также меня полностью убивает отсутствие в нем встроенного merge — для этой цели он нуждается во внешних подпорках типа diff3.Не вижу состава преступления — я могу использовать любую навороченную прогу, а не то, что они там себе придумали на коленке. unix-way;) > Для проекта с 500−1000 файлами его скорость вполне приемлемая.4 месяца назад раздражающе неприемлемая скорость на проекте из ~250 файлов.> 2All: я передам весь фидбек от этой статьи главным разрабам.О! Отлично!;) Они поимеют сторонника в лице меня, если догонят по скорости меркуриал и таки сделают наконец хоть какое-то подобие меркуриаловского hg-web. Отличная веб-морда, которая позволяет делать pull, push и просто смотреть через браузер всю историю и работает как CGI, FastCGI, из-под mod_python или mod_wsgi.А базар выложить на сервере для просмотра другим народом без клиента — просто нереально мучаться надо. Особенно учитывая, что он заметно меньше того же сабвершена распространён.> Также, если можно в цифрах, что Вы называете «медленно». Сча попробую.:)

2All: По просьбе одного из главных разрабов bzr Роберта Колинза.Ребята, все кто когда-нибудь пробовал bzr и говорит. что hg быстрее, пожалуйста приведите хотя бы ориентировочно версию bzr/hg и размер дерева исходников, на котором вы делали свои тесты. Также, если можно в цифрах, что Вы называете «медленно». Заранее спасибо, команде Bazaar важен любой фидбек.Он также предлагает всем попробовать новый pack format (для инициализации или апгрейда существующих ваших репозиториев используйте флаг —knitpack-experimental).Robert wrote: > hg was faster at everything; we’re now faster (for me) for a number of> things such as commit, and as folk keep pushing our infrastructure> improvements out to each command this will improve further.

2Макс, я ОЧЕНЬ сильно хочу это сделать. Я постараюсь. За 2 года накопилось много материала для статьи. (Я постараюсь.)

2Caujka: совершенно согласен. Причем большинство разрабов на полном серьезе так и живут — как будто англицкий единственный в мире язык.

Саша (bialix): как насчет сделать обзор всех популярных распределенных систем и опубликовать на ДОУ?;) Можно просто прислать текст на editors@, мы опубликуем.

Скопом отвечу всем.Главные фичи bzr: юзеро-ориентированность (почти все команды дейсвуют по принципу DWIM = do what I mean, [not what I write]); поддержка основных файловых серверов и протоколов (dumb servers): файловая система, share/samba/UNC, http/https, aftp/ftp, sftp/ssh, имеется плагин WebDAV (в вопросе «что такое интеграция с апачем» я честно говря некомпетентен, потому что апач мне не нужен). Плюс нативно поддерживается централизованная работа CVS-like. Главные цели, которые ставит перед собой команда bzr, — простой интуитивно понятный интерфейс в стиле «It Just Works», поддержка dumb-серверов, опциональная централизованная модель работы, высокопроизводительный smart-server а-ля централизованный сервер в svn. Тем, кто плотно работает с svn рекомендую посмотреть на плагин bzr-svn, который обеспечивает бесшовную работу с svn-сервером из bzr.У hg отличие в том, что она сделана ребятами, которые зарабатывают деньги на продвижении решений на основе Linux-платформы, отсюда их прохладное отношение к поддержке винды. Главные цели команды hg — скорость работы любой ценой, KISS (keep it simple stupid). Интерфейс пользователя вначале был скудный, со временем его стали причесывать. Не в последнюю очередь после встречи разрабов bzr и hg в мае 2006 — как результат bzr стала больше внимания уделять скорости и использовать некоторые идеи из hg, а hg стал больше уделять внимания пользовательскому интерфейсу и использовать некоторые идеи из bzr. Однако на самом деле, если внимательно ковыряться в деталях, то разницы между bzr и hg — предостаточно. Но это когда начинаешь вникать в детали. На первый взгляд они действительно выглядят похоже. Но под капотом — разные идеи и устремления.git — создан Линусом Торвальдсом для работы над ядром Линукса. Во многом создан под впечатлением от BitKeeper, но не является даже косвенным клоном. Главные цели команды git — удобство использования как это понимает Линус, скорость работы. Написан как смесь C+perl+shell-скриптов.По поводу «Mozilla выбрала hg». Во-первых, это экспериментальная ветка, а не основная. Полностью с CVS они не перешли. Кандидаты для замены CVS после долгого и тщательного отбора сузились до hg и bzr. В то время (февраль-март 2007) bzr далеко не блистал скоростью, что решило исход в пользу hg. Однако, сконвертировать CVS-репозитарий в hg им не удалось из-за ошибок в работе hg с юникодом. А вот bzr хоть и очень долго работал, но смог в конце-концов без потерь переконвертировать весь репозитарий. Алчущие подробностей — читайте в блоге Mozilla. Ищите по ключевым словам, гугля в помощь. Кстати там же была высказана уверенность, что они собираются повторить свой анализ спустя 9−12 месяцев. Потому что bzr старается работать хоть и медленно, но делать right thing. Кстати все оптимизации по скорости, которые ведутся командой bzr используют в качестве эталона как раз дерево исходников Mozilla. Я так подозреваю, что в начале 2008 года bzr попытается взять реванш.2Андрей Светлов: перевода на русский раньше 2008 года от меня скорее всего не будет. В ближайшие 2−3 месяца я думаю будет закончена борьба за скорость в bzr, будет выпущена версия 1.0. Наверное тогда и появятся переводы.Главная ценность и беда одновременно bzr — это то, что в нем самом внутри очень много функциональности. Однако это не дается даром. Мало того, что он писан на питоне (с небольшими C-расширениями), кторый сам по себе не самый быстрй интерпретатор, так еще и фичей под капотом, а значит и кода очень много. Одних только тестов при запуске прогоняется сегодня больше 9000 (больше девяти тысяч). Под виндой при этом падает не больше 20. Вдумайтесь в эти цифры. Сегодня уверенным лидером в скорости и скрипя зубами кроссплатформенности — да, является hg.Но на Линуксе git многим гораздо больше нравится.А под виндой bzr хоть и медленный, но более правильный.Короче нет серебрянной пули. У каждой системы есть свои достоинства и недостатки.Мне тоже кое-что не нравится в bzr, хотя я его активно использую уже 2 года. Но скорость как раз не самое худшее. Для проекта с 500−1000 файлами его скорость вполне приемлемая. Он не летает, но и не раздражает. Не «тормозит нереально», как утверждает Alexander Soloyov.2Андрей Светлов: спасибо за эту статью.: -) Я удивлен, что Вы решили все-таки попробовать Базар.2All: я передам весь фидбек от этой статьи главным разрабам. Спасибо за отклики которые уже есть и которые еще будут.

Реально работал, проблему не видел... Как-то так сложилось, что русских файлов и текста не надо было. Ну да ладно, значит, сосет: -) Оффтопик: мечтаю, чтобы в мире была только 1 кодировка и 1 раскладка клавиатуры. И 1 человеческий язык общения. Втихаря завидую пендосам, у большинства из них примерно так и есть. Вы бы видели глаза детишек, когда папик сказал: «Look at his laptop keyboard! »: -)

2bialix: Спасибо. Интересно услышать мнение от «непосредственно работающего лица».Это лицо, конечно же, одновременно и заинтересованное:) Приятно слышать, что со скоростью все не так уж и плохо.Я использавал 0.90.0. Проблем не замечал (может, не добрался до них).А удобство оценил.

пардон. status для дерева с русскоязычными именами файлов.Sorry за опеатку — я приболел немного.

darcs sucks.Я это обнаружил элементарно: сделайте diff (кажется это команда whatsnew) для файла с русским текстом. Или status (whatsnew -s) для файла в котором есть файлы с русскими именами. Под виндой — это абсолютно неприемллемое поведение.Плюс Red Giant bug.Сегодня фаворитами является тройка bzr, git, hg.

Рекомендую также посмотреть darcs — тоже очень удобен. По крайней мере, это мой первый опыт с распределенными репозиториями, и я на нем остановился.Интересен он тем, что глобально задумывался как инструмент для рефакторинга, и в историю пишется не просто разница, а изменения на более высоком уровне, как «переименовать переменную, а в абсолют».По-моему, для больших проектов все же лучше svn, как и-за скорости, так и из-за «порядка» в процессах.В прочем, преимущество распределенных систем контроля версий в том, что их можно использовать параллельно с любыми другими: -) Домашнюю работу брать, или просто работать сразу с парой локальных веток независимо, и чекинить по мере необходимости.

# Alexander Solovyov говорит: 30.10.2007 в 16: 31Базаар тормозит нереально просто.: (Меркуриал же, напротив, очень быстрый — быстрее сабвершена. Плюс меркуриал можно легко в апач привязать, а базаар — никак, только запускать отдельный сервер или ssh, что не очень удобно.Так что меркуриал — тхебест. Пока гит на винде не заработает нормально.:)

Базар тормозит — это факт, который я даже не буду оспаривать. Однако, за последние полгода ситуация кардинально изменилась: bzr все еще медленее hg, но нереальным я это называть не берусь. Чтобы не очернять Базар я попрошу Вас назвать версию bzr, которую вы пробовали последний раз. Или хотя бы приблизительно когда это было. Базар выпускает релизы по плану каждый месяц (иногда с небольшими задержками). Вчера вышел 0.92rc1 — все желающие могут пробовать. В этом релизе появился новый (пока экспериментальный) формат репозитория, который называется pack — по всем замерам он дает быстродействие сравнимое с hg. Так что попрошу не хаять.Меня в bzr подкупает его user-ориентированность. И то, что win32 для разработчиков — это ценная целевая платорма, в отличие от остальных двух. Кстати, я — maintainer windows версии.А hg я пробовал пару раз — и... не могу. Некоторые моменты субъективно кривые с точки зрения юзер-интерфейса. А также меня полностью убивает отсутствие в нем встроенного merge — для этой цели он нуждается во внешних подпорках типа diff3.PS: гит на винде не заработает нормально НИКОГДА.PPS: Не Базаар —, а просто Базар.

Спасибо за статью и за комментарии. Начинаю подумывать о переходе на mercurial; -)

вероятно, некоректно выразился.svn использую три года. Конечно, можно и после этого оставаться некомпетентным, но, надеюсь, это все же не так:)

"Поднимать локально svn — можно, но смешно"Автор некомпетентен в svn, что сводит ценность обзора к нулю.

Еще раз посмотрите на возможные workflow.Работа с bzr не навязвает единого стиля. Можно так, а можно этак.Можно «как в svn» — с единым сервером. Можно без него — если мы с другом мелочь мелкую быстро сделать хотим.А можно с «взятием работы на дом», длительной возни с веткой, локальными коммитами — и потом «возвращением в семью».Можно очень по разному. И способ работы тоже можно менять по мере необходимости, ничего проблемного в этом нет.По поводу mercurial: убедили, пошел смотреть. Хотя бы попробовать его, похоже, стоит.

2Родион Быков: можно и к Апачу

торренты без центрального сервера (трекера) всё-таки не обходятся. именно он отдаёт им информацию о других участниках «роя»., но это делается немного для других целей. ну или база собственная база узлов, которая может стать (и станет) неактуальной. нужна какая-то точка входа в распределённую сеть, которой будет скорее всего тот же самый центральный сервер или несколько серверов.вобщем да, «зачем это нужно? »

Чёрт, невнимательно читал. Допишу ещё.:) > откуда изначально импортировать дерево — найти человека с копией репозитория? Нету понятия «копия репозитория». Если ты себе скопировал репозиторий — то теперь репозиторий есть и у тебя. Да, изначально взять — клонировать чей-то.> На месте руководителя проекта фиг бы я отдал контроль над главным репозиторием.Ну так и не отдавай. В любом случае есть какой-то «канонический» репозиторий, откуда другие берут исходники. Просто ты можешь закоммитить не только туда, но и, например, на ноутбук своей бабушки, чтоб она могла пользоваться плодами твоего труда раньше других.:)

Базаар тормозит нереально просто.: (Меркуриал же, напротив, очень быстрый — быстрее сабвершена. Плюс меркуриал можно легко в апач привязать, а базаар — никак, только запускать отдельный сервер или ssh, что не очень удобно.Так что меркуриал — тхебест. Пока гит на винде не заработает нормально.:)

с остальными синхронизируете вы сами.

ну или другие со мной, насколько я понимаю.

Кстати, bzr status отлично отмечает эти изменения.

это понятно, но ci -m «comment» всё это закомитит ничего не спрашивая? имхо команда rm необходима.ну и присоединюсь к остальным коментаторам. тема распределённого репозитория не освещена. откуда изначально импортировать дерево — найти человека с копией репозитория? как узнать с кем надо синхронизироваться чтобы собрать все текущие изменения? получается, что сервер (или не сервер, но какой-то центр) должен быть.мне в голову приходит только одно применение: каскадный репозиторий. т.е. команда комитит в один репозиторий, потом эти изменения уходят в репозиторий стоящий выше, и т.д., но зачем это нужно — хз.

2Анонімно: с остальными синхронизируете вы сами. Теоретически после того, как система прошла все тесты:) Если bzr на момент commit видит, что файл удален — автоматически проводит его как операцию удаления.В svn нужно написать svn rm filename. В bzr достаточно просто удалить файл.Кстати, bzr status отлично отмечает эти изменения.

Не нужно говорить svn remove — bzr сам понимает, какие файлы я удалил.

т.е. если сделать ошибку в, например, make clean и случайно удалить файл, то bzr всё «поймёт» и удачно всё синхронизирует с остальными репозиториями?

На первый взгляд bazaar и mercurial очень похожи. Только Меркуриал работает гораздо быстрее того же SVN, а Базаар — гораздо медленнее.

2Саша: фишка базаара и прочих — возможность работы без единого сервера. Т.е. у каждого разработчика есть полное дерево версий.

Сразу предупреждаю — mercurial в глаза не видел. Про различия и сходство ничего сказать не могу. Как и о скорости — я пробовал на относительно небольших проектах. Где предел у bzr, после которого он начинает тормозить? Распределенная, или децентрализованная разработка предполагает необязательность единого сервера. Т.е. можно с ним, а можно и без него. Вот что пишут и рисуют на сайте bazaar

Привет, Андрей!

Хоть и пугала идея РАСПРЕДЕЛЕННОЙ разработки

Немного не въехал, в статье про это не слова. Осталось только ощущение, что bzr удобнее чем svn.

bzr достает своей тормознутостью (даже если не использовать деревья, —no-tree). Mercurial приятно удивил своей скоростью, по праву его выбрали для разработки в Mozill’e:)

А чем bazaar от mercurial по существу отличается, кто-нить знает? Сам юзаю mercurial, создалось впечатление, что если в статье заменить все слова bazaar/bzr на mercurial/hg, то получится статья про mercurial)

Я для ДОУ тоже подумывал уходить с subversion на bazaar/Mercurial. Но как-то все не решаемся, плюс надо кучу вспомогательных скриптов менять. Короче стремно. Но ты меня заинтриговал.;) Ссылки в тему: < ul>< li> Converting from Subversion to Mercurial</li>< li> плагин для Trac</li></ul>

Если понравились distributed VCS, может иметь смысл посмотреть (для общего образования) ещё на git и как тут подсказывали — mercurial (hg).git используется при разработке linux kernel (откуда и возник), xorg и ещё многого всякого; публичный хостинг водится, например, на repo.or.cz. Кусочки хинтов по-русски периодически водятся на freesource.info.

Подписаться на комментарии