О славной системе контроля версий. Vivat, Bazaar!
Андрей СветловОпубликовано 30.10.2007 в Инструменты, Разработка
Когда услышал о ней от Александра Бельченко (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 — не видел. Сказал свое ИМХО, а теперь кидайте в меня подушками!
Загрузка ...Понравилась статья? Подпишись на обновления по RSS/E-mail
Если понравились distributed VCS, может иметь смысл посмотреть (для общего образования) ещё на git и как тут подсказывали — mercurial (hg).
git используется при разработке linux kernel (откуда и возник), xorg и ещё многого всякого; публичный хостинг водится, например, на repo.or.cz. Кусочки хинтов по-русски периодически водятся на freesource.info.
Я для ДОУ тоже подумывал уходить с subversion на bazaar/Mercurial. Но как-то все не решаемся, плюс надо кучу вспомогательных скриптов менять. Короче стремно. Но ты меня заинтриговал.
Ссылки в тему:
А чем bazaar от mercurial по существу отличается, кто-нить знает?
Сам юзаю mercurial, создалось впечатление, что если в статье заменить все слова bazaar/bzr на mercurial/hg, то получится статья про mercurial )
bzr достает своей тормознутостью (даже если не использовать деревья, –no-tree). Mercurial приятно удивил своей скоростью, по праву его выбрали для разработки в Mozill’e
Привет, Андрей!
Немного не въехал, в статье про это не слова. Осталось только ощущение, что bzr удобнее чем svn.
Сразу предупреждаю - mercurial в глаза не видел. Про различия и сходство ничего сказать не могу. Как и о скорости - я пробовал на относительно небольших проектах. Где предел у bzr, после которого он начинает тормозить?
Распределенная, или децентрализованная разработка предполагает необязательность единого сервера. Т.е. можно с ним, а можно и без него. Вот что пишут и рисуют на сайте bazaar
2Саша: фишка базаара и прочих - возможность работы без единого сервера. Т.е. у каждого разработчика есть _полное_ дерево версий.
А к Apache можно прикрутить ?
На первый взгляд bazaar и mercurial очень похожи. Только Меркуриал работает гораздо быстрее того же SVN, а Базаар - гораздо медленнее.
т.е. если сделать ошибку в, например, make clean и случайно удалить файл, то bzr всё “поймёт” и удачно всё синхронизирует с остальными репозиториями?
2Анонімно:
с остальными синхронизируете вы сами. Теоретически после того, как система прошла все тесты
Если bzr на момент commit видит, что файл удален - автоматически проводит его как операцию удаления.
В svn нужно написать svn rm filename. В bzr достаточно просто удалить файл.
Кстати, bzr status отлично отмечает эти изменения.
ну или другие со мной, насколько я понимаю.
это понятно, но ci -m “comment” всё это закомитит ничего не спрашивая? имхо команда rm необходима.
ну и присоединюсь к остальным коментаторам. тема распределённого репозитория не освещена. откуда изначально импортировать дерево - найти человека с копией репозитория? как узнать с кем надо синхронизироваться чтобы собрать все текущие изменения? получается, что сервер (или не сервер, но какой-то центр) должен быть.
мне в голову приходит только одно применение: каскадный репозиторий. т.е. команда комитит в один репозиторий, потом эти изменения уходят в репозиторий стоящий выше, и т.д. но зачем это нужно - хз.
Обойтись без центрального сервера можно - ведь обходятся без него разные торренты, однако они должны жить “роем” и знать все друг о друге. У меня вопрос только в том, зачем это нужно
На месте руководителя проекта фиг бы я отдал контроль над главным репозиторием.
Базаар тормозит нереально просто.
Меркуриал же, напротив, очень быстрый - быстрее сабвершена. Плюс меркуриал можно легко в апач привязать, а базаар - никак, только запускать отдельный сервер или ssh, что не очень удобно.
Так что меркуриал - тхебест. Пока гит на винде не заработает нормально.
Чёрт, невнимательно читал. Допишу ещё.
> откуда изначально импортировать дерево - найти человека с копией репозитория?
Нету понятия “копия репозитория”. Если ты себе скопировал репозиторий - то теперь репозиторий есть и у тебя. Да, изначально взять - клонировать чей-то.
> На месте руководителя проекта фиг бы я отдал контроль над главным репозиторием.
Ну так и не отдавай. В любом случае есть какой-то “канонический” репозиторий, откуда другие берут исходники. Просто ты можешь закоммитить не только туда, но и, например, на ноутбук своей бабушки, чтоб она могла пользоваться плодами твоего труда раньше других.
торренты без центрального сервера (трекера) всё-таки не обходятся. именно он отдаёт им информацию о других участниках “роя”. но это делается немного для других целей. ну или база собственная база узлов, которая может стать (и станет) неактуальной. нужна какая-то точка входа в распределённую сеть, которой будет скорее всего тот же самый центральный сервер или несколько серверов.
вобщем да, “зачем это нужно?”
2Родион Быков: можно и к Апачу
Еще раз посмотрите на возможные workflow.
Работа с bzr не навязвает единого стиля. Можно так, а можно этак.
Можно “как в svn” - с единым сервером. Можно без него - если мы с другом мелочь мелкую быстро сделать хотим.
А можно с “взятием работы на дом”, длительной возни с веткой, локальными коммитами - и потом “возвращением в семью”.
Можно очень по разному. И способ работы тоже можно менять по мере необходимости, ничего проблемного в этом нет.
По поводу mercurial: убедили, пошел смотреть. Хотя бы попробовать его, похоже, стоит.
“Поднимать локально svn — можно, но смешно”
Автор некомпетентен в svn, что сводит ценность обзора к нулю.
вероятно, некоректно выразился.
svn использую три года. Конечно, можно и после этого оставаться некомпетентным, но, надеюсь, это все же не так
Спасибо за статью и за комментарии. Начинаю подумывать о переходе на mercurial
Базар тормозит — это факт, который я даже не буду оспаривать. Однако, за последние полгода ситуация кардинально изменилась: bzr все еще медленее hg, но нереальным я это называть не берусь. Чтобы не очернять Базар я попрошу Вас назвать версию bzr, которую вы пробовали последний раз. Или хотя бы приблизительно когда это было.
Базар выпускает релизы по плану каждый месяц (иногда с небольшими задержками). Вчера вышел 0.92rc1 — все желающие могут пробовать. В этом релизе появился новый (пока экспериментальный) формат репозитория, который называется pack — по всем замерам он дает быстродействие сравнимое с hg. Так что попрошу не хаять.
Меня в bzr подкупает его user-ориентированность. И то, что win32 для разработчиков — это ценная целевая платорма, в отличие от остальных двух. Кстати, я — maintainer windows версии.
А hg я пробовал пару раз — и… не могу. Некоторые моменты субъективно кривые с точки зрения юзер-интерфейса. А также меня полностью убивает отсутствие в нем встроенного merge — для этой цели он нуждается во внешних подпорках типа diff3.
PS: гит на винде не заработает нормально НИКОГДА.
PPS: Не Базаар — а просто Базар.
Рекомендую также посмотреть darcs - тоже очень удобен. По крайней мере, это мой первый опыт с распределенными репозиториями, и я на нем остановился.
Интересен он тем, что глобально задумывался как инструмент для рефакторинга, и в историю пишется не просто разница, а изменения на более высоком уровне, как “переименовать переменную а в абсолют”.
По-моему, для больших проектов все же лучше svn, как и-за скорости, так и из-за “порядка” в процессах.
В прочем, преимущество распределенных систем контроля версий в том, что их можно использовать параллельно с любыми другими
Домашнюю работу брать, или просто работать сразу с парой локальных веток независимо, и чекинить по мере необходимости.
darcs sucks.
Я это обнаружил элементарно: сделайте diff (кажется это команда whatsnew) для файла с русским текстом. Или status (whatsnew -s) для файла в котором есть файлы с русскими именами. Под виндой — это абсолютно неприемллемое поведение.
Плюс Red Giant bug.
Сегодня фаворитами является тройка bzr, git, hg.
пардон. status для дерева с русскоязычными именами файлов.
Sorry за опеатку — я приболел немного.
2bialix:
Спасибо. Интересно услышать мнение от “непосредственно работающего лица”.
Это лицо, конечно же, одновременно и заинтересованное
Приятно слышать, что со скоростью все не так уж и плохо.
Я использавал 0.90.0. Проблем не замечал (может, не добрался до них).
А удобство оценил.
Реально работал, проблему не видел… Как-то так сложилось, что русских файлов и текста не надо было. Ну да ладно, значит, сосет
Оффтопик: мечтаю, чтобы в мире была только 1 кодировка и 1 раскладка клавиатуры. И 1 человеческий язык общения. Втихаря завидую пендосам, у большинства из них примерно так и есть. Вы бы видели глаза детишек, когда папик сказал: “Look at his laptop keyboard!”
Скопом отвечу всем.
Главные фичи 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: я передам весь фидбек от этой статьи главным разрабам. Спасибо за отклики которые уже есть и которые еще будут.
Саша (bialix): как насчет сделать обзор всех популярных распределенных систем и опубликовать на ДОУ?
Можно просто прислать текст на editors@, мы опубликуем.
2Caujka: совершенно согласен. Причем большинство разрабов на полном серьезе так и живут — как будто англицкий единственный в мире язык.
2Макс, я ОЧЕНЬ сильно хочу это сделать. Я постараюсь. За 2 года накопилось много материала для статьи. (Я постараюсь.)
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.
> Или хотя бы приблизительно когда это было.
Конец июня этого года/начало июля. Сейчас скачаю новый, посмотрю.
> А также меня полностью убивает отсутствие в нем встроенного merge — для этой цели он нуждается во внешних подпорках типа diff3.
Не вижу состава преступления - я могу использовать любую навороченную прогу, а не то, что они там себе придумали на коленке. unix-way
> Для проекта с 500-1000 файлами его скорость вполне приемлемая.
4 месяца назад раздражающе неприемлемая скорость на проекте из ~250 файлов.
> 2All: я передам весь фидбек от этой статьи главным разрабам.
О! Отлично!
Они поимеют сторонника в лице меня, если догонят по скорости меркуриал и таки сделают наконец хоть какое-то подобие меркуриаловского hg-web. Отличная веб-морда, которая позволяет делать pull, push и просто смотреть через браузер всю историю и работает как CGI, FastCGI, из-под mod_python или mod_wsgi.
А базар выложить на сервере для просмотра другим народом без клиента - просто нереально мучаться надо. Особенно учитывая, что он заметно меньше того же сабвершена распространён.
> Также, если можно в цифрах, что Вы называете “медленно”.
Сча попробую.
Чем можно засечь время исполнения под виндой?
А у вас standalone installer?
если нет - то открыть файл bzr (у меня он в c:/python25/scripts)
и в начале написать
import sys
import time
t1 = time.time()
def exitfunc():
print ‘eplased time:’, time.time()-t1, ’secs’
import atexit
atexit.register(exitfunc)
Если очень нужно - можно и собрать версию с поправкой, чтобы переслать вам.
Вообще-то история лично у меня вызывает те же ощущения, что и переползания с CVS на SVN.
2Александр Соловьев: Поскольку время выполнения hg тоже интересно для сравнения, то наверное целеообразно использовать Process Monitor
http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx
В фильтр добавьте ProcessStart и ProcessExit
однако на моей системе сам ProcessMonitor жутко тормозит все процессы
Предлагаю: завтра я пересоберу bzr и hg по методу предложенному Андреем Светловым и выложу на к себе сайт.
Окей, давай так. Пока об ощущениях: есть проект на 163 файла, 24 ревизии в меркуриале и 1 базаре. Если делать инит без –knitpack-experimental, то базар где-то на порядок медленнее. Если с ним, то явного преимущества в скорости нету ни у того, ни у того. Проверяю на клонировании репозитория.
Ещё бы проверить это дело по сети (меня меркуриал подкупил скоростью, заметно быстрее сабвершена гоняет всё), но на сервер поставить релиз кандидат не представляется возможным. Завтра постараюсь выделить время погонять между двумя компами хотя бы.
Но базар ускорился. Определённо. Остался hgwebdir.
2bialix:
Спасибо вам за хорошие ответы.
Я консервативен в используемых системах облегчения жизни разработчика.
Долгое время меня устраивала svn, о чем вам не раз и писал.
Потом сменились внешние обстоятельства, и стало возможным поискать альтернативу - благо была одна на примете:)
Эксперимент считаю удачным для себя.
Буду рекомендовать друзьям и приятелям.
Кстати, а что вам НЕ ПОНРАВИЛОСЬ в Базаре?
На какие неудобства вы наткнулись?
Крайне интересно услышать критику от весьма знакомого с системой человека.
Скорость… В самом моем большом проекте было около 250 файлов. Неудобств по скорости не ощутил. Так же быстро, как и svn. Мне показалость приемлимым.
Конечно, было бы интересно оценить на моем последнем проекте.
Там было порядка 15 000 файлов в svn, и svn откровенно тормозила. Она тормозила заметно даже на другом проекте из 1500 файлов.
Из мелочей. В svn help тут же показываются короткие сочетания (update(up), commit(ci), checkout(co), move(mv), status(st) и т.д.)
В bzr это неочевидно. Понял, что оно работает - только забывшись и по привычке написав “как в svn”. А поправить так легко!
По поводу hgwebdir.
Если речь идет об вот таком: http://selenic.com/repo/hg
То у Базара есть loggerhead: http://codebrowse.launchpad.net/~bzr/bzr/trunk/files
(работает под 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.dev/en/user-guide/http_smart_server.html
В [f]cgi/mod_python/wsgi и прочей web-алхимии я не силен, поэтому на работе использую trac+bzr для просмотра текстов через web-интерфейс. Для push/pull/commit — sftp и bzr+ssh.
последнем - на предыдущей работе
“Конец июня этого года/начало июля.” — это скорее всего была версия 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`.
В bzr это называются alias к команде, встроенные alias можно увидеть в развернутом help к команде, например
C:\work\Bazaar\mydev>bzr help annotatePurpose: Show the origin of each line in a file.
Usage: bzr annotate FILENAME
Options:
--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.dev/en/user-guide/using_aliases.html
Мощная фича кстати.
На винде такие фокусы стоят много нервов. А винда для меня — главная платформа, хотя много пишу под Линукс
В bzr есть своя реализация 3-way merge, плюс есть возможность юзать diff3 если охота. При помощи плагинов ext-merge или difftools можно подключать сторонние мерджилки. Но меня встроеная во многом устраивает. А конфликты я со времен CVS научился править ручками в своем редакторе.
Теплый-холодный кеш (не знал, кстати, что они так зовутся) - известная беда.
Я привык оценивать свои ощущения по “теплому”. Ведь я системой пользуюсь постоянно, а не от случая к случаю.
По поводу сокращений: не спорю, настройка их - фича очень мощная.
В svn проблема алиасов решается так:
svn help
…
blame (praise, annotate, ann)
…
У вас бы могло быть
annotate (ann, blame, praise)
Если возможно, неплохо бы включить и настройки пользователя. Но это уже не важно.
По опыту - если человек такое видит - начинает использовать. Если нужно долго читать - не читает, пока случайно не наткнется. А вещь востребованная. Просто вы этого не видите, т.к. досконально знаете систему (по себе сужу). Не всегда вычитывается manual “от и до”. Гораздо чаще - “до состояния способности работать с системой”. Потом уже набирается нужный опыт - если задача заставляет лезть опять в manual.
А еще. Если алиасы можно настраивать - то почему бы не упомянуть последней строкой ссылку на http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/using_aliases.html? Хотя, может быть, последнее - лишнее.
Мелочь, как я уже говорил. Мне - не мешает. Но было бы приятно.
2 Родион Быков:
> На месте руководителя проекта фиг бы я отдал контроль над главным репозиторием.
Это логика CVS, здесь она неприменима (нет такого идиотского ограничения, как технически главный репо). Почитайте первую ссылку в первом комментарии
2 Alexander Solovyov:
> Так что меркуриал - тхебест. Пока гит на винде не заработает нормально.
Ну вроде чо-то с той стороны недавно доносилось, хотя для меня было радостней услышать про оптимизации в gitk, которые позволяют использовать его для всей истории всего linux kernel (почитал про 250/500/1000 файлов — стало грустно, git на средних-то проектах шуршит *очень* быстро, а большими не давится).
2 Caujka:
> И 1 человеческий язык общения.
Это типа “слава роботам” было?..
*sigh*
2 bialix:
Спасибо за отзывы, статью по сумме было бы интересно почитать (хотя windows bias даёт свои перекосы — как же вам там, бедным, тяжко с инструментарием…)
>> unix-way
> На винде такие фокусы стоят много нервов.
Ну так это проблемы винды, простите. Вон сколько времени угробили на поиск аналога банального time(1)…
Кстати по поводу мержей — git уже научили mergetool и звать при возможности meld, tkdiff, vimdiff или ещё полдюжины всякого-разного на помощь
> Юзер также может настраивать свои alias
Да, это отличная штука. Мне её не хватает в меркуриале.
> На винде такие фокусы стоят много нервов. А винда для меня — главная платформа, хотя много пишу под Линукс
Я тоже сижу на винде, но проблем не испытал, честно говоря. Поставил kdiff3, написал строчку в конфиг - и всё работает.
> Ну вроде чо-то с той стороны недавно доносилось,
Я слежу за гитом, пока никаких подвижек. Т.е. его-то запускают, но он тормознутый до ужаса.
> почитал про 250/500/1000 файлов — стало грустно
> хотя windows bias даёт свои перекосы — как же вам там, бедным, тяжко с инструментарием…
100%. Но так как отказаться не могу, то - mercurial.
> (работает под TurboGears)
Это плохо.
> Тут написано, что интегрируется: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/http_smart_server.html
Хо! Научили, вроде. Надо попробовать. Делать push через ssh я себе не могу позволить - не могу заводить на каждого коммиттера аккаунт на сервере.
windows bias — это только у меня. Практически 99% разработчиков используют Linux, четверка главных разрабов вообще получает зарплату в Canonical Ltd.
По поводу kdiff3 и прочего: портированный на windows diff3 всегда сохраняет выходной файл с CRLF концовками, даже если исходные файлы имели LF-only. kdiff3 тоже я так понимаю имеет эту проблему — видел по этому поводу открытый баг в трекере Mercurial. Так что встроенная merge — это очень жЫрный плюс для меня
А на рахунок monotone, Хто що може сказати?
2Alexander Solovyov:
Андрей Возница из Львова подсказал другой метод измерения времени, через дополнительную программку. Вот собственно результат:
http://www.bialix.com/bzr-win32/timeit.exe
Киньте ее в любую папку, которая у вас в путях, потом просто пишите timeit перед вызовом bzr/hg, например:
timeit bzr –no-plugins init
и т.п.
Она напечатает время выполнения программы в секундах. Пойдет?
monotone: из поколения первых распределенных систем. Использует sqlite для хранения репозитория. Много внимания уделяется интегральной целостности репозитория — поэтому она насквозь пронизана sha1-хешами кругом. Даже номера ревизий — и те формируются из хешей. Этим она мне не понравилась. Я поставил, почитал доку — как-то все запутанно и накручено. Из тех отзывов, что я читал в сети — скоростью не блещет.
> Она напечатает время выполнения программы в секундах. Пойдет?
То что надо, просто аналог time из никсов. Вечерком замерю всё.
> Из тех отзывов, что я читал в сети — скоростью не блещет.
Зачем отзывы, она реально не блещет.
Однако! Осталось попробовать его серверную часть, и действительно можно будет сказать “Виват, Бозар!” (это не ошибка, это Фоллаут ;))
Вот батник, которым тестировал:
@echo off
cd bzrcx
timeit C:\Python25\python.exe C:\Python25\Scripts\bzr init --knitpack-experimental .
timeit C:\Python25\python.exe C:\Python25\Scripts\bzr add -q
timeit C:\Python25\python.exe C:\Python25\Scripts\bzr ci -q -m "initial"
cd ..
timeit C:\Python25\python.exe C:\Python25\Scripts\bzr clone -q bzrcx bzr1
timeit C:\Python25\python.exe C:\Python25\Scripts\bzr clone -q bzrcx bzr2
timeit C:\Python25\python.exe C:\Python25\Scripts\bzr clone -q bzrcx bzr3
cd hgcx
timeit hg init .
timeit hg add -q
timeit hg ci -q -m "initial"
cd ..
timeit hg clone -q hgcx hg1
timeit hg clone -q hgcx hg2
timeit 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, но меня в принципе не волновала абсолютная производительность. Можно сказать, что они действительно сделали хорошую работу. Сделали б полгода назад - в сторону меркуриала и не взглянул бы.
Итак, на очереди сетевая версия. Когда доберусь - не знаю.
Эмм… Тег code как-то плохо сработал.
Поддержка маркдауна какого-нибудь была бы неплоха…
Александр — спасибо за цифры. Я перешлю их в наш список рассылки.
Кстати, видно что вы тестировали скомпилированный hg.exe и чисто питоновский bzr.
Замечу, что скомпилированный bzr.exe имеет меньшее время старта, поэтому при запусках его в ваших тестах цифры для bzr были бы меньше на 100-200 мс. Это конечно крохи, но все таки факт имеет место быть.
Формат knitpack пока еще экспериментальный, не все еще части тщательно оттюнингованы. Если Вас не затруднит провести свое сравнение через месяц-два, я был бы рад вас уведомить о выходе новой версии, когда этот формат станет основным.
> Замечу, что скомпилированный bzr.exe имеет меньшее время старта,
Упс. У меня просто дома трафик, потому качал что поменьше. Буду знать.
> Если Вас не затруднит провести свое сравнение через месяц-два
Не затруднит, работы-то не много для этого надо.
Я надеюсь, что ещё найду время насетапить базар на сервер, чтоб проверить, как оно там работает. piranha AT piranha.org.ua
P.S. Не, я таки напишу Максу по поводу маркдауна.
да, размер инсталлятора меня самого беспокоит. к сожалению там не так просто уменьшить, хотя есть что выкинуть.
открыл группу ru_bzr: http://groups.google.com/group/ru_bzr
Я наверное не очень вьехал в тему. Кто мне обьяснит, как распределнный репозиторий потом мержит хистори двух веток, которые разрабтывались какое-то время отдельно друг от друга, без синхронизации? Ну пример: я анбиндился от репозитория, сделал 10-ток багофиксов (ка каждый по 1-2 комита у себя). В то же время пара дургих разработчиков делала тоже по 10-20 комитов отбинденые от остальных. И естественно каждый мой комит мог зацепить те же строчки, что и у моих товарищей. По-моему потом с ними синхронизироваться будет уже не возможно, т.к. чтобы в итоге была полная хистори изменений и можно было посмотреть, кто, что в какой момент и для чего изменял. Я так понимаю либо история изменений теряется и все ченжесы мержаться одним комитом? Мне кажется, что все таки централизованная svn лучше именно тем, что имеется четкая хистори всех изменений. И я точно помню, что вот эту строчку я менял такого-то числа, когда фиксил вот этот баг.
В svn ветки потому и заводятся по серьезным причинам. Потому, что их нужно периодически синхронизировать и когда я смотрю хитори основной ветки и вижу там комит с коментарием “merged with branch” то я могу пойти и посмотреть лог того бранча. Но представьте себе сколько будет проблем посмотреть номарльно лог, когда у нас практически весь хистори основной ветки будет состоять из комитов-синхронизаций? Хотя может и не так проблемно, как кажется. Я конечно не пробовал.
Вот именно, что просто намного лучше, чем в svn всё сделано. Ты видишь все чейнджсеты, более того, есть программы, которые не напрягаясь рисуют график что и когда с кем было смержено в данном текущем репозитории.
Во первых, когда вы делаете ветку в svn - это действительно серьезная причина. Новая экспериментальная версия или серьезный багфикс.
В базаре ветка делается для того, чтобы вы сделали свои изменения. Личные.
Другой разработчик сделал то же.
Как потом быть? Да так же, как и в svn, только удобнее.
Можно мержить параллельные ветки и, добившись совместной работы, выложить это в trunk.
Или еще куда нибудь (наша_совместно_собранная_ветка.dev)
Можно попытаться запостить свое первым - привет, svn, кто последний, тот и латка (в смысле именно он разбирается с конфликтами). У нас на работе это нередко превращалось игру.
Если все изрядно запутано - много разработчиков, они не сидят рядом, каждый ведет свою ветку - то тоже все видно. Кто когда и как менял.
И, самое главное, что я увидел - свобода.
Желаешь работать “как в svn” - работай. Желаешь сделать ветку - делай. Она не отразится в главном репозитарии. Если хочешь ее засветить - свети. Склеивай с другими. Работай локально - и потом склеивай.
Можно базар рассматривать как “svn с большими степенями свободы”, но этим он не исчерпывается.
Централизованный svn - можно так и на базаре. А можно и иначе (причем для каждого разработчика).
Кому что нравится. Осваивать новое можно в процессе использования.
Базар дает больше гибкости, на мой взгляд. Не накладывая ограничений.
Все не так, все горяздо проще.
1) В bzr нет понятия “синхронизироваться”. Есть понятие — “объединиться” (merge). При объединении две ветки пытаются соединить в одну точку. Если в разных ветках были внесены исправления в одну и ту же строку в каком-то файле, то вы получите конфликт. Однако это не влияет на процесс объединения. Конфликты вы разрешаете либо ручками в своем любимом редакторе, либо при помощи спец.программ типа WinMerge и т.п.
2) Само по себе объединение не создает новой версии или записи в истории. После объединения новую версию исходников нужно фиксировать как обычно. После этого в логе вы будете видеть все версии (revision) из другой ветки, которые вы объединили со своими.
3) Для того, чтобы посмотреть кто когда и что менял имеется команда annotate, которая для каждой строчки файла показывает номер последней ревизии, в которой были внесены исправления, а также кто и когда.
В bzr вам не надо куда-то идти. Это видно сразу.
Ще є такий distributed version control: monotone.
Хто-небудь пробував?
Найкращі відгуки як про дистрибутивний контроль версій я чула про darcs, збираюся спробувати.
Втім, якщо немає потреби у дистрибутивному контролі версій, то немає особливого сенсу на нього переходити. Бо він буде повільнішим і ризик галудження вищий. Потім мерджити зайвий раз, навіть якщо не важко, все одно влом.
Ось гарне порівняння різних SCM:
http://better-scm.berlios.de/comparison/comparison.html
> Бо він буде повільнішим
Какие-то ущербные представления о DVCS у тебя. Я перешёл везде на меркуриал там, где мог это сделать, просто потому, что он намного быстрее svn работает. Просто на порядки. И выше я жаловался на производительность базара, который тоже работает быстрее сабвершена.
Попробуй устриц, а уж потом ругай их.
Alexander Solovyov, а які Ви маєте на увазі операції, коли говорите про продуктивність?
Локальні операції, безсумнівно, будуть у DVCS швидшими. А щодо не-локальних - ой не погоджуюся. Аж цікаво стало, чому у вас svn повільно працює…
Будь-яка розподілена система має переваги у надійності над централізованою. Але й у централізованої є переваги: немає додаткових вимог щодо синхронізації, відстежування цілісності репозиторіїв (окрім свого), а отже вона є швидшою (ми ж не говоримо про розподілені обчислення, так?).
Тобто я хочу сказати, що середньостатистично DVCS є повільнішою за СVCS. Я на семінарі по темі DVCS виступала
Якщо не вірите мені, ось почитайте документик про спеціалізовану мініатюрну DVCS на Distr. Hash Table - Pastwatch. Там у кінці є бенчмарки, порівняння із CVS. Уявіть собі, навіть у порівянні із CVS по багатьох операціях програє.
http://pdos.csail.mit.edu/papers/pastwatch:nsdi06.ps.gz
> Alexander Solovyov, а які Ви маєте на увазі операції, коли говорите про продуктивність?
Общие ощущения. Я делаю десяток-два коммитов локально, а потом закидываю их на сервер. И это выходит быстрее, продуктивнее и заметно менее опасно в плане поломки чьего-то кода, нежели работа с свн.
> Уявіть собі, навіть у порівянні із CVS по багатьох операціях програє.
Не знаю, что за специализированная DCVS, но я не вижу медленности меркуриал при push’е или pull’е. Я вижу только медленность svn. Я не проводил никаких тестирований, никаких исследований, но общее ощущение - заметно быстрее. Ну раз так в несколько на глазок. Один и тот же проект стянулся из mercurial’а быстрее, чем из svn - но сервера разные (хоть и одинаково далеко от меня находятся практически), потому тут утверждать нечего.
Но что это не медленно - это 100%.
Шановний Александр Соловьёв,
ну я не прихильниця міряти “на глазок” та “по общим ощущениям” )))
Може, у вас свн криво до апача прикручений… чи https маєте на увазі (там свн донедавна тормозив). Це все частинні випадки.
А ж говорю про загальні тенденції, зумовлені архітектурою цих софтяр. Про це ж свідчать і бенчмарки.
Я не “наїжджаю” на DCVS, просто наголошую на тому, що в них є своя ніша, свої переваги та недоліки.
> делаю десяток-два коммитов локально, а потом закидываю их на сервер. И это
> выходит быстрее, продуктивнее и заметно менее опасно в плане поломки чьего-то
> кода, нежели работа с свн.
Знаєте, я би сказала, що саме у такий спосіб небезпечно користуватися… Принаймні якщо ви працюєте не сам, а в команді. Бо ви так зробите пару десятків локальних комітів, і ваш колега аналогічно, а потім кинетеся синхронізуватися і мерджити гілку, що виникла, - замахаєтесь
> ну я не прихильниця міряти “на глазок” та “по общим ощущениям” )))
Ну я тоже, но время замерять лень.
> Може, у вас свн криво до апача прикручений
В каком смысле?
> чи https маєте на увазі
https - это вообще непотребство, а не скорость.
> Я не “наїжджаю” на DCVS, просто наголошую на тому, що в них є своя ніша, свої переваги та недоліки.
Логично. Но я просто говорю о том, что недостатка скорости не видно. Как-то оно вполне так живенько работает.
> а потім кинетеся синхронізуватися і мерджити гілку, що виникла, - замахаєтесь
Так в svn то же самое. Я просто реже коммичу, и точно так же есть вероятность напороться на мерж. Не так это и напряжно.
> середньостатистично DVCS є повільнішою за СVCS
Дивні люди — роблять статистику там, де або зустріну динозавра (робить швидко), або ні (гальмує).
Ну то й не їжте середньостатистичну ковбасу
Повторюся — вищезгаданий git навіть як локальний однокористувацький інструмент контролю версій *для мене* має купу переваг над cvs, починаючи від git mv/checkout -b та далі у бік можливості push’нути додому — як для бекапу, так і на випадок, коли дома офлайн та можна ще щось там наколупати (в однокористувацькому, знов-таки, режимі).
А про мержи — є інструменти, де це аврал, а є — де це стиль роботи й норма, тому цей процес якомога автоматизовано та полегшено. Висновки залишаються читачеві
Чим воно краще? Там Bazaar навіть не згадується. Це що, так тепер роблять об’єктивні порівняння, просто вилучаючі конкурентів з списку?
Пані SC, виступати на семінарі, та мати досконале уявлення про розподілені системи керування версіями — це дуже різні речі. Усі Ваші коментарі говорять лише про те, що Ви й гадки не маєте про що говорите.
> Пані SC, виступати на семінарі, та мати досконале уявлення про розподілені
> системи керування версіями — це дуже різні речі.
Ну, це безумовно
Втім, з деяких семінарів, та ще на згадану Вами тему, взашию виженуть, якщо побачать недостатній рівень підготовки доповідача.
> Усі Ваші коментарі говорять
> лише про те, що Ви й гадки не маєте про що говорите.
Аргументуйте, шановний(а)! Прошу Вас!
А Ви добре розумієтесь на архітектурі дистр. контролів версій? Я, чесно, добре знаю архітектуру лише однієї із таких систем. Але до того ж я знаю певні риси та вимоги до дистрибутивних систем в цілому. Оскільки такі вимоги вищі, аніж до централізованих систем, то очікувати, що рішення будуть легшими, щонаймешне наївно.
> > Ось гарне порівняння різних SCM:
> > http://better-scm.berlios.de/comparison/comparison.html
> Чим воно краще? Там Bazaar навіть не згадується. Це що, так тепер роблять
> об’єктивні порівняння, просто вилучаючі конкурентів з списку?
bialix, мисліть ширше! Я не упереджена ані до базару, ані до дистр. контролю версій. І не моя провина, що у цьому порівнянні базар не згадали, просто це одне із найбільш багатосторонніх та систематизованих порівнянь, яке я бачила.
Мене просто вражають необ’єктивні статті та відгуки захоплень про нові дистрибутивні SCM. Вони, звичайно, хороші, але не панацея! А дехто саме як панацею їх і розцінює. Це занадто суб’єктивно. Дистрибутивний софт хороший там, де потрібна дистрибутивність, а там де вона не обов’язкова, знайдеться швидше працюючий спеціалізований софт.
Якщо хтось переконаний, що конкретна софтяра фуричить швидше, то де Ваші аргументи? Статистичні аналізи по конкретних операціях - віддалених комітах, апдейтах тощо. Наводьте і аргументовуйте!
>> середньостатистично DVCS є повільнішою за СVCS
Дивні люди — роблять статистику >там, де або зустріну динозавра (робить швидко), або ні (гальмує).
>Ну то й не їжте середньостатистичну ковбасу
мабуть, ми з різних планет… знаєте, у мене різний софт на різних операціях та за різних умов із різною швидкістю працює
і далеко не завжди це можна виміряти “на око”.
сподіваюсь, вам ніколи не доведеться розробляти софт для повітряної подушки в машині…
>Повторюся — вищезгаданий git навіть як локальний однокористувацький інструмент >контролю версій *для мене* має купу переваг над cvs, починаючи від git >mv/checkout -b та далі у бік можливості push’нути додому — як для бекапу, так і >на випадок, коли дома офлайн та можна ще щось там наколупати (в >однокористувацькому, знов-таки, режимі).
де ви бачили, щоб я рекламувала cvs як кращий за інші контроль версій??? :))))))) та йому ж >20 років! ))