Что можете сказать про СУВ Bazaar?

мозгов у недоразработчиков этого поделия

Неплохая вещь, но интерес к ней в последние годы резко упал у всех. Собственно, как и к другим альтернативам git. При всех недостатках git, использовать что-то другое сейчас не очень практично.

Что можете сказать про СУВ Bazaar?

Скорее мертв, чем жив

Ну не очень. Медленный, не сильно понятный.

Единственная интересная фича — launchpad, без него Bazaar давно бы помер.

Лучше выбрать git/hg.

чего так?

Скорее мертв, чем жив

Хочу потыкать его палочкой

«потыкать его палочкой» (с)

некрофил :)

Судя по последнему релизу, оно вполне себе пилится, так почему бы не потыкать :)

Bazar уже одной ногой в могиле, вторая уже на подходе.

Уж лучше Mercurial/hg... :)

Зачем пользоваться говном, когда можно не пользоваться.

Из праздного любопытства. И потом, наверняка bzr содержит все необходимые команды(инструменты), с помощью которых решаются задачи, для которых она создана. Вот git к примеру, куча команд, ключей, в каждом релизе вводится что-то новое, а вы все из этих фич используете? Или только 30% функционала, потому что вам больше и не требуется и вродекак ххватает? Я не защищают bzr, мне просто любопытно... Судя по последнему релизу, она будет поддерживаться как минимум 5 лет, так если она свои задачи выполняет, чего напрягаться и чего в ней плохого?

Или только 30% функционала

Да хоть 1%. Оно работает и оно популярно (git), а значит все ответы гуглятся на раз.

С bzr работал в паре с ланчпадом - тормозит страшно.

Заодно подскажите, на LP можно создавать бесплатные закрытые репозитарии для своего кода как на butbucket или только за денюжку?

Без понятия. У меня был открытый.

https://bitbucket.org - бесплатные закрытые, Mercurial и git

Раньше было ограничение в 5 приватных реп. Сейчас сняли?

а вы все из этих фич используете? Или только 30% функционала, потому что вам больше и не требуется и вродекак ххватает?

Следуя этому принципу надо пользоваться самым тупым и примитивным инструментом, не развиваться и не хотеть новых фич и решений. Слишком пассивная позиция, стране нужен такой электорат, молодец.

Лучше потыкай darcs. Там хоть оригинальные идеи есть. А во всех этих спорах гито-меркуриал-базарофагов толку нету.

It's dead, Jim.

Так как проект Bazaar находится в состоянии стагнации список изменений достаточно скромен и включает 20 исправлений, расширение тестового набора и одно улучшение.

Очень тяжело, наверно, зайти на главную, и прочитать заголовок: «Unlimited private repositories».

У меня их уже 30-ть реп. Ограничение было и остается - для всех репозиториев максимум 5 совладельцев, например 10 репозиториев у тебя 3 коллеги имеют доступ, к еще 15-ти все 5 коллег, т.е. всего 5 максимум коммитеров в репы, т.е. пять морд.

Первопроходцам я верю охотнее, чем рекламным буклетам.

Спасибо. Раньше было ограничение — не более 5 приватных реп на морду.

не развиваться и не хотеть новых фич и решений.

Большой поток изменений является признаком плохого качества(какого-то из) текущего решения - от добра добра не ищут. Пользоваться им только потому, что популярно и быстро изменяется - спорное решение. Ибо так можно быстро нарешать проблем, которых у других, может быть, вообще не было, и обнаружить, что альтернативы получившемуся монстру из костылей вымерли.

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

Смею заметить, что подавляющее большинство возможностей Mercurial использовать легко и просто, не прибегая к гуглению. В то время как в git некоторые примитивные вещи мне приходится делать либо через дополнения (ставить их отдельно вручную) либо долго неочевидно гуглить так оно еще и внезапно может не заработать, даже простейшая работа с ветками.

Я работаю с git, но с огромной неохотой. Всё личное - это hg.

Я признаю, что git - это вершина возможностей и фич. Но они мне не нужны. А нужна предсказуемость и проста использования, без головняка. Mercurial(hg)/TortoiseHg дает большинству разработчиков все необходимые возможности без излишних страданий. Обожаю hg за продуманность и простоту.

Я никогда не использовал hg, по большей части из-за таких вот евангелистов как вы. Такое безаргументированное восхваление - первый звоночек для меня.

Я использую git, по очевидным причинам, но не пишу об этом на каждом углу. И не пытаюсь доказать каждому встречному, что он лучше других. Использование hg вместо git, имхо, - признак синдрома «не такой как все».

Не. Это использование git там, где он не вперся («потому что начальники сказали перейти на гит!») — признак стадного инстинкта и «модно в этом сезоне» :) Люди, привыкшие к Perforce по историческим причинам, вообще не понимают как работать в гите :) А первый, кого заметят за использованием гита, станет «тыжзнаешьгит» и все ему будут говорить «какое дерьмо твой гит».

Если нужно выложить сорцы на самый популярный хостинг сорцов в мире (github) - выбирать не приходится. Ни о каком стадном эффекте речи и не идёт. Банальная необходимость.

где он не вперся

Есть конкретные проблемы от использования git для определенных задач? Кроме теоретической простоты альтернатив.

Если нужно выложить сорцы на самый популярный хостинг сорцов в мире (github)

Ненужно :) Ты проиграл :)

Есть конкретные проблемы от использования git для определенных задач? Кроме теоретической простоты альтернатив.

Есть конкретные проблемы: паралич работы проекта с налаженными процессами которые уже работают и не сломаны :)

Что можете сказать про СУВ Bazaar?

Ненужно.

Аргументы уровня ЛОР. Другого и не ожидалось.

А напрасно. Какие еще должны быть аргументы у «тупо проще»? Причем я как раз тот, кто использует git в том числе. Я абсолютно уверен что git может стать удобным если его тщательно изучить, но то что в git требует изучения, в Mercurial у новичка работает тупо сразу. Простота - философия создателя hg.

Кроме теоретической простоты альтернатив.

Для меня это факт.

Большой поток изменений является признаком плохого качества

Моя мысль касательно «хотеть новых фич и решений» была исключительно про осознание проблем и вырастание из рамок текущего инструмента. Ченьжлог не подразумевался.

Причем я как раз тот, кто использует git в том числе.

Ты уже пять лет используешь git, а до сих пор не осилил. Не осилить тупую навигацию по графу ревизий. С тобой что-то не так.

Какие еще должны быть аргументы у «тупо проще»?

Как минимум: задание X делается 1-й командой в VCS A, и 3-я в VCS B.

Я не знаю как можно сделать еще проще тот набор фич, что мне нужны: pull, push, commit, tag, checkout, branch, rebase, merge.

Приводить примеры бессмысленно, просто надо посадить двух новичков и дать им задания на те или иные действия с репозиториями (один git другой hg). Ответ будет найден быстро. И когда внедряешь где-то новую DVCS, новичков может быть много.

Я вот тоже использую hg по возможности и счастлив! Git, в основном, по работе в команде. Честно говоря, гит - он для ботов, не для людей. Через SourceTree ещё можно использовать, там различий между hg и git нет. А вот через терминал сидеть с гитом при наличии и возможности юзать hg + Bitbucket - это, мягко говоря, консерватизм.

В то время как в git некоторые примитивные вещи мне приходится делать либо через дополнения

Ты щас намекаешь, что ухитряешься использовать mercurial без дополнений? Да это нонсенс.

осознание проблем и вырастание из рамок текущего инструмента

Это тоже - в этом случае говорим о качестве «соответствие области применения». Допливание «идеального» для одних условий/задач/процессов инструмента до состояния приемлемого для других (у/з/п) не обязательно является разумной стратегией, т.к. при небольшом попрании лени можно научиться использовать сразу «идеальный» для последних (у/з/п), буде таковые окажутся актуальны.

У тебя? Безусловно :) Но по-прежнему не нужен гит на проекте, где прекрасно жили с Perforce — ради гита что ли? Пеар в духе переезда в новый офис «там вид из окна хороший» — последнее из-за чего норм. люди поедут в новый офис :) Интеграция с гитхапом тоже нифига не актуальна при принципиально закрытых проектах, собственных ДЦ «ворлдвайд» и амазонооблаках для не очень важных вещей :)

Я не знаю как можно сделать еще проще тот набор фич, что мне нужны: pull, push, commit, tag, checkout, branch, rebase, merge.

checkout, update, commit :) — там, где DVCS нафиг не нужны, с их кучей крутых команд и аж несколькими конфликтующими воркфлоу (у которых обязательно есть парочка авторитетных аблакатов), но в данном проекте только усложняют процесс, вызывая оторопь у людей, которые не собирались заморачиваться апстримами, фич-ветками, пулл-реквестами и прочей «интеграцией с гитхапом» (просто не требуется — нету столько версий кодебейс, никакой опенсорц рядом не валялся, а история гладенькая получается искаропки без задрочек с ребейсами :)) — итого им CVCS хватает за глаза и за уши, а форсят им git дезориентированые манагеры и любители «поставить процесс» (которым нравится просто «ставить процессы», вместо работы) не от большого понимания издержек на конкретных проектах.

Настолько сырой поток сознания я не перевариваю, увы.

Не, ты просто дислексию не лечишь, но топишь за git почем зря.

Тут потыкал его малость, не догоняю одну вещь, у bzr ветки это нечто большее чем ветки у других систем? Т.е ветка это больше в смысле «отпочкование» проекта или изменение вектора развития, а не просто некая сущность в рамках репозитария? А сама по себе ветка, имеет линейное развитие - просто набор ревизий, следующих друг за другом? Погуглил, мол отдельная ветка это целый репозитарий, это как? О_о