LINUX.ORG.RU

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

 bitkeeper,


0

4

Известная распределённая система контроля версий BitKeeper стала доступна под свободной лицензией Apache 2.0.

Особенности:

  • Простой в использовании интерфейс командной строки
  • Вложенные репозитории: подмодули, сделанные правильно. Используйте контроль версий для контроля коллекций из репозиториев.
  • Гибридный режим для двоичных файлов, который использует отдельные серверы для двоичных файлов вместо того, чтобы забивать ими репозитории с исходным кодом.
  • Отслеживание файловых операций, таких как создание, удаление, переименование.
  • Все операции с файлами проверяют контрольные суммы для целостности. Все файловые записи включают избыточную информацию для коррекции ошибок.
  • Очень точный алгоритм слияния, который использует полную историю для разрешения конфликтов. Большинство других систем используют разные вариации diff3.
  • Просмотр аннотированного исходного кода (добавление информации о дате, авторе, и т. д. при просмотре содержимого файла).
  • Высокая производительность и масштабируемость до очень больших репозиториев.
  • Лицензирован под Apache Version 2.

Готовые сборки доступны для дистрибутивов Debian, Fedora, Ubuntu, RHEL, а также для Windows, OS X, FreeBSD и NetBSD.

Git-зеркало на GitHub

>>> Подробности

★★★★★

Проверено: tailgunner ()
Последнее исправление: cetjs2 (всего исправлений: 3)

Ответ на: комментарий от i-rinat

А это разве не очевидно было?

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

andreyu ★★★★★
()
Ответ на: комментарий от i-rinat

Имя же известное. Не было бы BitKeeper, не появился бы Git в том виде. Изначальные идеи оттуда пришли.

Да, я когда-то читал историю появления git. Нужно будет освежить в памяти.

andreyu ★★★★★
()
Ответ на: комментарий от tailgunner

Боятся? По-моему, они нерелевантны уже... когда там выросло первое поколение github-«программистов»? Короче, уже несколько лет.

Раскопал несколько комментов Ларри на HN:

год назад

thomasfl: I wonder if BitKeeper owner Larry McVoy has ever regretted not open sourcing his software? Git tools is a whole industry now. The most promiment one, github, recently become one of the 100 most popular websites on the planet.

luckydude: Regret it? Sure. I'd do it in a heartbeat if I could figure out how to make it work. Still would and there is plenty in BK that Git doesn't have. Like submodules that actually work exactly like a monolithic tree, just lets you clone what you need. But we've never figured out how to make it work financially. If anyone has any ideas I'm all ears (though pointing at github and saying «do that» isn't an idea that I can execute). BTW, BK used to be pretty darned close to open source, you got the source code under a funky license that said «don't take out the part that lets us make money». We stopped shipping the source when we learned that the very first thing that someone committed to the repo was taking out the part that let us make money.

сегодня

luckydude: This is to answer this question and all the «too late» comments. Too late? Maybe. But we had a viable business that was pulling in millions/year. The path to giving away our stuff seemed like: step 1: give it away step 2: ??? step 3: profit! And still does. So what changed? Git/Github has all the market share. Trying to compete with that just proved to be too hard. So rather than wait until we were about to turn out the lights, we decided to open source it while we still had money in the bank and see what happens. We've got about 2 years of money and we're trying to build up some additional stuff that we can charge for. We're also open to being doing work for pay to add whatever it is that some company wants to BK, that's more or less what we've been doing for the last 18 years. Will it work? No idea. We have a couple of years to find out. If nothing pans out, open sourcing it seemed like a better answer than selling it off.

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

Legioner ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Я не думаю, что у bk есть преимущества над системами на криптохешах. ЕМНИП, у bk какая-то очень хрупкая реализация распределенными - при средней квалификации гит-фанбоя это будет смертельно :) Вот алгоритм мержа могут позаимствовать.

tailgunner ★★★★★
()

Ирония судьбы в том, что никто не верит в иронию судьбы. Если в 80-ых/90-ых ещё можно было торговать всякими keyrus'ами, да arj'ками, то сейчас, с лавиноподобным количеством опенсорса _приемлемого_качества_, просто нереально делать деньги на всяких перделках - их проще написать десятку энтузиастов, чем покупать даже при цене в 10 рублей - гемор со всеми этими му_ацкими регистрациями и оплатами того не стоит.
До сих пор удивляюсь обилию коммерческого софта, который давно прошёл рубикон «есть альтернатива» и даже впал в разряд «уже ненужно», но при этом продолжающийся продаваться. Кому это устаревшее гогно нужно??
Вот и биткипер, имя которого я встречаю второй раз в жизни, опомнился :)) - неужто его разрабы настолько тупы и слепы, что профукали аж целых два опенсорсных продукта у себя под носом?! (Hg и Git) Закапывайте уже этот бомжкипер, ненужно.

Все файловые записи включают избыточную информацию для коррекции ошибок.

Хм... нафига? Это не версионника дело следить за коррекциями, а файловой системы. А ресурсы потрачены. А код висит и требует внимания. И тестов. И никогда не исполняется у юзера. биткиперцы - гении! :)

matumba ★★★★★
()
Ответ на: комментарий от matumba

Они (по своему опыту) считают чексуммы очень полезной фичей.

Это не версионника дело следить за коррекциями, а файловой системы.

Файловые системы не считают это своим делом и не следят за этим. Твои предложения?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Некоторые файловые системы не считают это своим делом и не следят за этим. Твои предложения?

Заменил твой квантор всеобщности на квантор существования.

anonymous
()
Ответ на: комментарий от Legioner

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

А ведь в свое время в начале девяностых Ларри Маквой приложил немало усилий, пытаясь убедить успешных менеджеров Sun открыть код Solaris. Если б его тогда послушали, никакого этого вашего ляликса и не было бы. А теперь от сам в подобной ситуации оказался...

anonymous
()
Ответ на: комментарий от Legioner

luckydude: This is to answer this question and all the «too late» comments. Too late? Maybe.

Мужик, ты нас не слышишь? Не maybe, а too late, и отвечать нам не надо.

t184256 ★★★★★
()

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

Долго они соображали...

В любом случае - новость отличная!

ps: Теперь Линус сможет забить на свой git и вернуться на BitKeeper! :D

Indexator ★★★
()
Ответ на: комментарий от buratino

лучше поздно, чем git

Всё равно push прийдётся делать. Хахахахахаха!!!1111одын

rupert ★★★★★
()

Линус забросит git и вернётся на него?

h4tr3d ★★★★★
()
Ответ на: комментарий от rupert

Такое радиоактивное говно, что лучше его закопать поглубже и никогда не откапывать.

бррр... поддерживаю, два года с ним жить и работать пришлось. Без CM в нём вообще закопаться можно.

h4tr3d ★★★★★
()
Ответ на: комментарий от DoctorSinus

А Ганс Рейзер когда освободится?

А когда Рейзер_4 попадёт в ядро?

anonymous
()
Ответ на: Возможно никогда от Camel

Ему надо, как Брейвику, заявить о нарушении его прав и потребовать в камеру комп с доступом в инет, тогда он сможет слать патчи... :D

Indexator ★★★
()
Ответ на: комментарий от rupert

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

gns ★★★★★
()
Ответ на: комментарий от slonopotamus

Ок:

  • частичная децентрализация (плюс с гитом можно более адекватно скорячить, но до этого руки попробовать не дошли)
  • встроенные средства проксирования и репликации
  • дифалка работала ну значительно шустрее, да и вообще оно было поворотлевее SVN на наших репозиториях.
  • легко собрать несколько отдельных веток в рабочую копию (не знаю как лучше это описать словами). Плюс можно собрать билд конфигурацию: например пилишь новый функционал, который достаточно изолирован, делаешь ветку для него отдельного, а остальное дерево берёшь из основной ветке, собираешь вместе и получается новая рабочая копия. Удобно.
  • Шелвы для обмена снипетами. Особенно при отладке, дабы не обмазывать код #ifdef/#else/#endif.
  • ещё какие-то мелочи, типа более гибкой политику управлением правами доступа

но цена конская, поэтому компания отказалась в пользу svn.

И git мне удобнее и привычнее :)

h4tr3d ★★★★★
()
Последнее исправление: h4tr3d (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Файловые системы не считают это своим делом и не следят за этим

<trollmode>zfs set checksum=on pool/volume</trollmode>

Pinkbyte ★★★★★
()
Ответ на: комментарий от eao197

У них на сайте интересные циферки публикуются: https://www.bitkeeper.com/features_performance

Как-то слишком круто. Помнится в одном из своих выступлений Линус втирал, какой git супер шустрый. А тут он ближе к плинтусу.

andreyu ★★★★★
()
Ответ на: комментарий от Legioner

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

А других претензий нет.

gns ★★★★★
()
Ответ на: комментарий от Pinkbyte

А как ты думаешь в чём разрабатывают git или mercurial? В них самих же, вестимо

Ни git, ни mercurial не являются средствами разработки.

andreyu ★★★★★
()
Ответ на: комментарий от eao197

Интересные комментарии

У них на сайте интересные циферки публикуются: https://www.bitkeeper.com/features_performance

Интересно было бы почитать комментарии почему получаются такие цифры. Если смотреть только на графики, то складывает впечатление, будто git писали умственно отсталые школьники на переменке после «информатики», а bitkeeper — профессоры и чемпионы по оптимизации. Однако мы знаем, что это не так. Git тоже не дураки писали, и всякую операцию которую он делает, он делает не случайно, а по какой-то причине. Если bitkeeper работает настолько быстрее, то чем ради этого пришлось пожертвовать?

Git, например, работает гораздо быстрее hg (на проектах среднего размера, проекты гигантского размера сейчас давайте не будем рассматривать). Но этому есть объяснение: hg хранить чуть больше исторической информации о взаимоотношениях ревизий (если я правильно понял это), которую git считает ненужной.

Camel ★★★★★
()
Последнее исправление: Camel (всего исправлений: 1)
Ответ на: комментарий от Indexator

Асашай страна свободы

Ему надо, как Брейвику, заявить о нарушении его прав и потребовать в камеру комп с доступом в инет, тогда он сможет слать патчи... :D

Не путайте кислое с длинным. Брейвик сидит в Норвежке, там можно писать формулировки в духе «мучительно устаревшая Sony Playstation». Райзер сидит в СШП, где одно из условий соглашения о сокращении срока до возможного досрочного освобождения, я просто охренел, отказ от оспаривания решений суда. Разве вообще можно так делать? Разве у них в конституции не закреплено право на судебную защиту? В таком виде тюремное заключение превращается из исправительной меры в настоящую пытку: хочешь подать на УДО пораньше — навсегда откажись от права доказать в суде свою невиновность.

Camel ★★★★★
()
Ответ на: комментарий от DoctorSinus

Уточнение

А Ганс Рейзер когда освободится?

Почитал Википедию, вроде бы не 2021 год, а 2019.

Camel ★★★★★
()
Ответ на: комментарий от Pinkbyte

Окей, перефразирую, «какую VCS используют для разработки git и mercurial»?

Для разработки, полагаю, никакую.

andreyu ★★★★★
()
Ответ на: комментарий от good_riddance

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

gns ★★★★★
()
Ответ на: комментарий от andreyu

никакую

wrong

pinkbyte@oas1 ~ $ cat /usr/portage/dev-vcs/git/git-9999.ebuild  | grep REPO_URI
EGIT_REPO_URI="git://git.kernel.org/pub/scm/git/git.git"
pinkbyte@oas1 ~ $ cat /usr/portage/dev-vcs/mercurial/mercurial-9999.ebuild | grep REPO_URI
EHG_REPO_URI="http://selenic.com/repo/hg"
Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Для разработки нужен текстовый редактор и компилятор. Система контроля версий - это нужный и удобный инструмент, но с его помощью ничего не разрабатывают.
Что вообще вы пытаетесь показать/доказать?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Для разработки нужен текстовый редактор и компилятор. Система контроля версий - это нужный и удобный инструмент, но с его помощью ничего не разрабатывают.

facepalm.jpg

tailgunner ★★★★★
()
Ответ на: комментарий от matumba

Это не версионника дело следить за коррекциями, а файловой системы. А ресурсы потрачены. А код висит и требует внимания. И тестов. И никогда не исполняется у юзера. биткиперцы - гении! :)



Как отмечали ниже ,файловая система не следит за целостностью.А когда у гита не было системы коррекции(или хотя бы цифровой подписи) можно крупно нарваться, как когда-то случилось (3-5 лет назад) у проекта KDE ,распределенный репозитарий,архивация,и т.д ,обновления происходили автоматом по крону ,у одного из главных серваков слетел раид, восстановление прошло не корректно .Что то из мелких проектов оказалось повреждено,когда кинулись оказалось что обновились уже на 2 под версии,все сервера обновились,хорошо у кого то оказался бэкап :-(

maximnik0 ★★
()
Ответ на: комментарий от tailgunner

> Это не версионника дело следить за коррекциями, а файловой системы.
Они (по своему опыту) считают чексуммы очень полезной фичей.

Сударь, вы путаете чексумму с кодом коррекции ошибок. Чексуммы - нужны, коррекция - нет.

matumba ★★★★★
()
Ответ на: комментарий от andreyu

Полагаю, что следующим постом вы поясните свою точку зрения?

После того, как ты пояснишь свою. Обоснуешь, что VCS не оказывает помощи при разработке.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.