BitKeeper освободился

Это потому, что тогда популярным был не zip и rar, а arj.

Кстати правда, напомнили, тогда же перед поездкой (или переливом через мопед) уточняли какие архиваторы есть на принимающей стороне. Я ведь на такие грабли тоже наступал, например на дискете .arj приезжаешь а у клиента его нэма, да или просто встретившись в институте передаешь дискету сокурснику а он потом не может открыть. Позже sfx от rar-а очень в тему пошел.

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

Ха-ха, нет. В лицензии BK тогда был пункт о запрете разработки конкурирующих продуктов, а среди разработчиков ядра оказался один из разработчиков Mercurial. В этом был конфликт.

Ха-ха, нет.

У Торвальдса были вполне конкретные требования к VCS:

Torvalds wanted a distributed system that he could use like BitKeeper, but none of the available free systems met his needs, particularly in terms of performance. Torvalds cited an example of a source-control management system requiring 30 seconds to apply a patch and update all associated metadata, and noted that this would not scale to the needs of Linux kernel development, where syncing with fellow maintainers could require 250 such actions at a time. For his design criteria, he specified that patching should take no more than three seconds, [7] and added an additional three points:

• take Concurrent Versions System (CVS) as an example of what not to do; if in doubt, make the exact opposite decision [9]
  
• support a distributed, BitKeeper-like workflow [9]
  
• include very strong safeguards against corruption, either accidental or malicious [8]

These criteria eliminated every then-existing version-control system except Monotone. Performance considerations excluded this, too.

И он написал VCS которая в первую очередь решает задачу версионирования ядра Linux. ВНЕЗАПНО, результирующая программа оказалась довольно полезной и для других проектов, что в принципе нормально в мире свободного софта.

Да, на некоторых сценариях Git медленее других VCS. И если ваши сценарии использования VCS ограничены только ими - да, конечно, нет смысла использовать Git. Но in real world, вам будут нужны также и те сценарии, на которых Git быстрее/удобнее. В результате возникает многокритериальный выбор, где к разным критериям надо подставлять коэффициенты, чтобы понять какая VCS в целом подходит лучше. Ну и как-то так получается, что во многих случаях Git оказывается предпочтительнее других VCS.

Интуиция подсказывает, что существование VCS, превосходящей уже существующие во *всех* real-world сценариях, невозможно в принципе.

Так было и с CVS, и с SVN

А как с ними было? Мы вполне осознанно перешли в то время с CVS на SVN из-за его киллер-фич:

• Атомарные коммиты
  
• Неразрушение истории при переименованиях
  

Ну и как-то так получается, что во многих случаях Git оказывается предпочтительнее других VCS.

Замечательно. Мне вы это зачем объясняете?

Интуиция подсказывает, что существование VCS, превосходящей уже существующие во *всех* real-world сценариях, невозможно в принципе.

Соглашусь с вашей интуицией. Но было бы неплохо узнать, зачем вы это говорите?

Повторю еще раз: разработчики BitKeeper показали цифирь, доказывающую, что на определенных сценариях BK быстрее, чем git. Это хороший маркетинговый ход с их стороны.

Само наличие таких сценариев не должно вызывать удивления, т.к. не смотря на высокую скорость работы git-а у него наверняка есть узкие места. Как и у любого другого инструмента. И ничего удивительного, что разработчики BK (за деньги, работая над своим продуктом full-time), смогли где-то в чем-то обогнать git. Да еще и учитывая, что BK появился гораздо раньше. А сам git был написан ну в очень короткие сроки.

Удивление вызывает то, что это кого-то удивляет.

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

Так было и с CVS, и с SVN.

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

А бенчи от разработчика bk ни о чем.

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

С BK как-то грустно все с документацией, как мне показалось. Нет какого-то плавного введения в тему. По крайней мере на поверхности. А колупаться в куче разрозненных man-файлов лень, да и времени нет.

может пора обновить git до текущей версии?

Вроде бы не сильно отстаю. Под Arch-ем вообще очень свежий git. Другое дело, что когда нет внешних требований использовать git, то я с удовольствием использую вместо него hg.

*Мои* основные претензии именно к P4 (без общих для P4 и SVN, они довольно похожи):

• Адовый workflow по созданию/мержу бранчей. Это вам не «svn cp http://server/trunk http://server/branches/<branch> + svn merge» и уж тем более не «git checkout -b <branch> + git merge <branch>»
  
• Необходимость на сервере настраивать расположение клиентских working copy, полная дурь
  
• До недавнего времени неспособность автоматически провести мерж если в одной из веток файл был изменен, а в другой переименован
  
• Далекие от удобства command-line тулзы, т.к. в первую очередь P4 предполагает использование GUI
  
• Практически полная потеря функциональности при отсутствии подключения к серверу
  
• Дополнительные шаманства при изменении файлов при помощи софта, ничего о P4 не знающего
  
• Ну и цена
  

В общем я пока не встречал проекта, для которого P4 был бы более предпочтительным чем SVN. Из самого крупного над чем работал (P4 вроде как в первую очередь позиционируется для больших проектов с большими командами): 500K ревизий, 30GB (1M файлов) working copy, 2TB репозиторий. Живет этот монстрик в SVN.

Это слабый маркетинговый ход. Они говорят «BK быстрый когда у вас working copy лежит в NFS». Вы много знаете людей/проектов, которым это нужно?

Блин, действительно нет. Я перепутал с другим скандалом, связанным с BK.

Это слабый маркетинговый ход.

Сильно зависит от целевой аудитории.

Вы много знаете людей/проектов, которым это нужно?

Не много. Тем не менее, они есть и что им делать? Жрать кактус или взять BitKeeper?

Вы уверены, что BitKeeper позиционируется как инструмент для широкого круга пользователей? Вот у меня лично такого впечатления не возникло. По нынешним временам это явно очень нишевый продукт. Вот и выпячивается свойство, которое нужно далеко не всем, но уж если нужно, то выбор совсем небольшой.

А как с ними было?

Как написал eao197 - «огромное количество разработчиков не знают ничего, кроме ЛЮБАЯ_VCS_ИЗ_СПИСКА-а».

Я тоже перешел в свое время с cvs на svn. Много позднее перебрался на git, чему весьма рад.

Повторю еще раз: разработчики BitKeeper показали цифирь, доказывающую, что на определенных сценариях BK быстрее, чем git. Это хороший маркетинговый ход с их стороны.

«Тайд лучше, чем обычный порошок*»
* в качестве обычного порошка мы использовали мел.

Почему мел-то? Вроде в их бенчмарке совершенно рутинные операции, ничего необычного.

Вроде бы не сильно отстаю.

Это я в упрек заявлению, что гит был написан в краткие сроки. Никто не заставляет использовать «ту самую» версию :)

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

Часто такое слышу, но никто не может внятно объяснить, чем ртуть лучше гита.

Почему мел-то?

Вероятно потому, что мое нутро интуитивно отказывается верить в такие цифры.

Вроде в их бенчмарке совершенно рутинные операции, ничего необычного.

Вы пробовали повторить их бенч на своем проекте? Думаю многим было бы интересно узнать результаты такого бенча.

Никто не заставляет использовать «ту самую» версию

А что, принцип работы git-а сильно изменился с годами?

Часто такое слышу, но никто не может внятно объяснить, чем ртуть лучше гита.

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

А что, принцип работы git-а сильно изменился с годами?

Так проблема в принципах работы гита?

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

git init
git add .
git ci
git push

В ртути это делается проще?

Так проблема в принципах работы гита?

Часто встречал сетование на то, что git blame работает долго, особенно на больших репозиториях с длинной историей. Чем это еще объясняется, как не принципами его работы?

В ртути это делается проще?

А ты пользуешься только этими командами?

Они там тесты делают на NFS, а Git на NFS не очень хорошо работает. Помнится для Git-а нужно было всякие выкрутасы делать, чтобы он NFS не загружал lstat-ами. Git заточен на локальную файловую систему, где он действительно супер шустрый.

Если bitkeeper работает настолько быстрее, то чем ради этого пришлось пожертвовать?

Ключевое слово: NFS. Зная, что Git делает гиганское количество операций с файлами, которые он считает быстрыми (lstat), они специально поставили Git в такие условия, где lstat будет медленным.

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

Так и было. А потом взрослые дяди дали Линусу пару подзатыльников и он исправился.

https://news.ycombinator.com/item?id=1221756

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

Нет, они сказали, что поставь Git репо на NFS и Git будет сливать. А не надо держать Git репы на NFS. Одно из следствий того, что Git - distributed VCS, это то, что нет никакой необходимости держать репы централизованно.

Вон в cvs теги можно в код встроить, а в git нет. Это недостаток git?

Ты не поверишь, мне некоторые доказывали, что rcs id - это супер фича, и без неё никуда. А mixed revision working copy в SVN - это мега фича. А в гите этого всего нет, и сначала они пытаются эти фичи туда запихать, а потом объявляют, что Git - говно.

Часто встречал сетование на то, что git blame работает долго

Попробуй `tig blame`: http://jonas.nitro.dk/tig/screenshots/blame-view.html

Прикольно смотреть, как он распараллеливает вычисление blame коммитов для каждой строки в файле.

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

Часто встречал сетование на то, что git blame работает долго, особенно на больших репозиториях с длинной историей. Чем это еще объясняется, как не принципами его работы?

А возможную причину уже описывали выше по треду.

А ты пользуешься только этими командами?

Нет, но этих команд достаточно для новичка.

Они там тесты делают на NFS, а Git на NFS не очень хорошо работает.

А если сравнить обе системы на локальной файловой системе?

Попробуй `tig blame`: http://jonas.nitro.dk/tig/screenshots/blame-view.html

Кстати да, tig - одна из лучших морд для гита.

А возможную причину уже описывали выше по треду.

Извини, не видел. Видел высказывания в духе «сделали как надо, потому что так надо было». Что не противоречит моему мнению. Сделали как надо было Линусу. Многим понравилось.

Из чего вовсе не следует вывода о том, что нельзя сделать лучше. И что кто-то не сделал лучше. Для определенных сценариев использования.

Нет, но этих команд достаточно для новичка.

Если оставаться в рамках этих команд, то никакого профита от git-а нет.

Сделали как надо было Линусу.

Похоже, что так оно и было.

Многим понравилось.

Так это же хорошо :)

Из чего вовсе не следует вывода о том, что нельзя сделать лучше.

Всегда можно сделать лучше.

И что кто-то не сделал лучше. Для определенных сценариев использования.

Ну вот bk сделал не лучше, а просто хорошо поиграл условиями бенча.

Если оставаться в рамках этих команд, то никакого профита от git-а нет.

Профита по сравнению с чем? Можно ли работать с cvs и svn локально так, как позволяет dvcs? Насколько удобна работа с бранчами у cvs и svn?

Так он тетрисы для ондроедов клепает, откуда он про разработку может знать?

Из истории появления git-а.

Из истории же вы должны знать, что Линусу очень не интересно было разрабатывать git. Не интереснее было бы только базу данных разрабатывать.

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

С земною осью ешё никто не сталкивался, а с O(N²) - многие. И я очень не уверен в том, обеспечить такую эффективность работы толпы из N человек исключительно обсуждаемыми инструментами вообще возможно.

Осталось понять, что вы хотели этим доказать.

Так он тетрисы для ондроедов клепает, откуда он про разработку может знать?

Энтерпрайз-девелопер, когда уже винда станет юзабельна и менее корява, чем она есть сейчас?

Всегда можно сделать лучше.

О том и речь.

Ну вот bk сделал не лучше, а просто хорошо поиграл условиями бенча.

Ну пусть так. Вон Facebook тоже чегой-то играл, играл с условиями бенчей, а потом extension для Hg сделал и все.

Нормальный процесс. Не понятно, почему любителей git-а это так задевает.

Профита по сравнению с чем?

С другими DVCS. С hg, bzr или monotone.

Я вот не понимаю, зачем вы мне это все говорите. git сделали для конкретных целей в очень сжатые сроки. Результат устраивает кучу народу. Чуть меньшая куча вполне успешно на этом пилит деньги инвесторов зарабатывает. У пользователей git-а все славно и замечательно. Аминь.

Что вовсе не исключает возможности получить DVCS с характеристиками, лучшими, чем у git-а. По крайней мере по определенным параметрам. Вот BitKeeper это продемонстрировал.

Ну и какие проблемы? Думаете, что кто-то плюнул в ваш любимый инструмент?

git сделали для конкретных целей в очень сжатые сроки

git пилят сотни человек больше десяти лет. git используют для больших и очень больших проектов. Разработчики похваляются высокой производительностью, которая действительно заметно выше других VCS. И тут приходит BK, якобы работающий в 100500 раз быстрее. Два варианта объяснения этого феномена: * разработчики git *и всех остальных VCS* профнепригодны; * кое-то маненько брешет.

Думаете, что кто-то плюнул в ваш любимый инструмент?

Я думаю, что кое-кто маненько брешет.

// любитель hg

Нормальный процесс. Не понятно, почему любителей git-а это так задевает.

По треду видно, что нервничают почему-то противники гита.

С другими DVCS. С hg, bzr или monotone.

Вы смело можете использовать любые команды, а не только из приведенного мною списка.

Два варианта объяснения этого феномена: * разработчики git *и всех остальных VCS* профнепригодны; * кое-то маненько брешет.

Какой удивительно узкий взгляд на вещи. Есть еще одно возможное объяснение: есть специфические ниши, в которых git не используется, поэтому для этих специфических ниш git не пилят. И в правильно созданных условиях эксперименты показывают результаты не в пользу git-а.

При чем здесь профпригодность или непригодность?

Вы смело можете использовать любые команды, а не только из приведенного мною списка.

Так в том-то и дело, что как только выходишь за рамки pull/add/commit/push, так hg и bzr осваиваются без проблем. А git с трудом.

Что вовсе не исключает возможности получить DVCS с характеристиками, лучшими, чем у git-а. По крайней мере по определенным параметрам.

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

Вот BitKeeper это продемонстрировал.

Бенчи, проводимые фрониксом выглядят более правдиво, а они известные махинаторы.

Так в том-то и дело, что как только выходишь за рамки pull/add/commit/push, так hg и bzr осваиваются без проблем. А git с трудом.

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

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

Повторюсь: там есть ссылки на репозитории. Все желающие могут взять и посравнивать самостоятельно. Только вместо этого флейм о том, «могут или не могут разработчики git-а быть профнепригодными».

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

Откуда взялось «значительно удобнее»?

Речь про то, что мне лично (повторюсь: лично мне), проще запомнить, как работать с hg, чем с git-ом. Врожденная тупость или старческая деменция, но вот с hg влет понимаешь, как и что форкнуть, а потом слить. А с git-ом нужно помнить про local и remote branches, про теги, которые нужно пушить отдельно, про checkout -b и пр. вещи.

Вот и возникает вопрос: а нахрен это все, если мне нужны совершенно обыденные вещи, а не весь комплект навороченной функциональности git-а?

Иногда я скачиваю код не с Github. Ня тех сервисах нельзя открыть коммит в веб-интерфейсе, и скачать старую версию программы. Но можно скачать самый последний гит, а затем откатить его назад. Задачка для эрудитов! Как это сделать? Ответ завтра!

P.S. Жалко что с помощью GIT нельзя скачать сразу старую версию. Или можно?

Есть еще одно возможное объяснение: есть специфические ниши, в которых git не используется, поэтому для этих специфических ниш git не пилят. И в правильно созданных условиях эксперименты показывают результаты не в пользу git-а.

Я что-то не вижу на их сайтике упоминаний о специфических условиях. Они просто пишут «МЫ БЫСТРЕЕ», а если для этого нужно прострелить себе ногу использованием NFS, то это относится к категории «маненько брешут».

Можно, но это делается крайне неудобно.

Ну блин. С точки зрения меня - гентушника - SVN удобее. Запускаешь kdesvn, выбираешь revision 5601... Или вообще ebuild выбираешь. Но юзеры пофиг - девелоперс, девелоперс, девелоперс! А потому GIT...

С точки зрения меня - гентушника - SVN удобее. Запускаешь kdesvn, выбираешь revision 5601...

% git clone --depth 1 --branch v6.6.6