BitMover maakt versiebeheersysteem BitKeeper open source

Het versiebeheersysteem BitKeeper is onder een opensourcelicentie vrijgegeven door het bedrijf BitMover. De software werd tussen 2002 en 2005 bijvoorbeeld gebruikt voor versiebeheer van de Linux-kernel, maar werd vervangen door Git.

Op de site van BitKeeper staat aangegeven dat de software beschikbaar is onder een Apache 2.0-licentie. Phoronix meldt dat de ontwikkeling ervan door blijft gaan. Tot nu toe was de software eigendom van BitMover, dat deze in het verleden gratis beschikbaar stelde aan bepaalde ontwikkelaars, waaronder Linus Torvalds. Hij gebruikte de software voor het versiebeheer in Linux, wat toentertijd voor enige ophef zorgde, omdat de broncode niet vrij beschikbaar was en Linux volgens velen juist een voorbeeld van open software moest zijn.

In 2005 besloot BitMover te stoppen met de ontwikkeling van de gratis versie BitKeeper, omdat er pogingen werden ondernomen een clone van de software te ontwikkelen. Degene achter deze pogingen was Samba-ontwikkelaar Andrew Tridgell, die de clone 'SourcePuller' had gedoopt. Daardoor moest ook Torvalds op zoek naar een nieuwe oplossing. Een aantal weken na de beslissing van BitMover presenteerde Torvalds een zelfgeschreven alternatief met de naam Git.

Deze software wordt nog steeds gebruikt, naast alternatieven zoals Apache Subversion.

Reacties (35)

[fameus]

"In 2005 besloot BitMover te stoppen met de ontwikkeling van BitKeeper,"

Helemaal niet waar. BitKeeper wordt nog steeds ontwikkeld en verkocht.
Je bedoeld waarschijnlijk dat de "free-to-use" versie werd gestopt in 2005, dat is wel waar.
Ik betwijfel of alles open source wordt. BitKeeper heeft nogal wat (prijzige) enterprise modules.

[Reactie gewijzigd door fameus op 22 juli 2024 16:49]

[Rafe]

Alles wordt open source volgens de ceo:

We decided to go all in on open source. Given our history, anything but a "here ya go" license wasn't going to go over well. We're aware that someone could fork it and compete against us, good on them if they can. Making money in this space isn't easy and if they can do better than us we'll ask 'em for a job. We know the source base

[Anoniem: 334725]

Ik betwijfel of alles open source wordt. BitKeeper heeft nogal wat (prijzige) enterprise modules.

Vaak word het omgezet naar een support contract bij dit soort producten. Bekendste voorbeeld is RHEL

[Rafe]

Wie interesse heeft in vraag & antwoord met ceo Larry McVoy van BitMover: op de Hacker News-thread reageert hij onder de username luckydude. Zo had BK al ruime tijd ondersteuning voor (grote) binaire bestanden in de repository (iets dat met git-lfs pas recent brede ondersteuning geniet) en zouden submodules/subtrees beter moeten werken (gebruik ik zelf niet).

Persoonlijk vond ik dit interessant:

This is buried but in case anyone reads it, the real reason to open source BK is to show the world that SCM doesn't have to be as error prone or as complicated as Git. You need to understand how Git works to use it properly; BK is more like a car, you just get in and drive.

Git was in eerste instantie bedoeld als een low level toolkit om een gebruiksvriendelijk versiebeheersysteem bovenop te bouwen. Ik denk dat dat ik niet de enige was die in het begin een succesvolle non-fast forward merge of rebase zag als een stukje magie dat ik niet helemaal begreep. Naar verluidt zouden ook Bazaar en Mercurial eenvoudiger zijn in het gebruik, maar gezien de enorme populariteit van git heb ik nog niet echt een reden gehad om er mee aan de slag te gaan.

Als je het nog steeds magisch vindt: dankzij deze tutorial ben ik het een stuk beter gaan snappen

Hoewel git voor open source nu de de facto standaard is, zijn er nog sectoren waar het weinig gebruikt wordt. Vanwege de gebruiksvriendelijkheid als goede ondersteuning voor binaire assets is Perforce de populaire keuze in de gamesindustrie - niet-technische mensen (artiesten) kunnen er ook mee werken Nog zat kansen voor BitKeeper dus.

[Reactie gewijzigd door Rafe op 22 juli 2024 16:49]

[Snow_King]

Lijkt mij behoorlijk kansloos in deze wereld waar Git de grote winnaar lijkt te zijn? Bijna alle Open Source projecten die ik zie gebruiken Git.

Ook heerlijk om mee te werken, vele malen fijner dan SVN als je het mij vraagt.

[Bas_f]

Ik vind het altijd jammer om te lezen dat mensen SVN maar aan de kant schuiven, omdat de meeste mensen GIT gebruiken en het (mede) door Linus is ontwikkeld en daarom wel goed zal zijn. Als ik dan vraag wat er echt beter is aan GIT, dan komt er nooit echt een bevredigend antwoord.
Zoals ik het zie hebben beide versiebeheersystemen hun eigen voor- en nadelen en toepassingen voor de diverse soorten softwarontwikkeling. Persoonlijk vind ik GIT prettiger voor het ontwikkelen van applicaties en SVN prettiger voor het ontwikkelen van webapplicaties/websites.

[MadEgg]

SVN mist fatsoenlijke rebasing, distributed repositories en daarmee offline werken en lokale branches, en sowieso is, IMO, de manier waarop tags en branches 'geimplementeerd' zijn als shallow copies ipv first-class citizens zeer lelijk.

Ik heb een tijd SVN gebruikt voordat ik op GIT overstapte en was direct om. Kan me nu niet meer voorstellen hoe ik ooit uit de voeten kon met SVN.

[FragFrog]

Want we zijn zo vaak offline? En daarom gebruikt ook ongeveer iedereen die iets met GIT doet GIThub als effectief een centrale server?

Dat hele idee van patches in e-mailen (wat ook met SVN natuurlijk kan) was leuk in 2005, maar inmiddels niet echt meer relevant. Blijft over branching en tagging waar GIT het eerst beter deed, maar waar SVN vrij snel ook goed mee overweg kon. Als ik dan de eerste desktop clients bekijk was TortoiseSVN vele malen duidelijker en handiger in gebruik dan de CLI van GIT, of de latere GUI apps die alle "GIT-magie" behapbaar probeerden te maken.

En vooral dat laatste is toch wel een bekend probleem van GIT.

[MadEgg]

Ik gebruik géén GUI voor git (noch SVN). Ik werk met de command line. Ik kan me best voorstellen dat dat voor anderen belangrijk is maar voor mij speelt dat geen enkele rol. Ik heb gewoon een dag of twee gespendeerd aan het leren werken met git en sindsdien is er weinig magisch meer aan.

Overigens kan Eclipse prima overweg met GIT, en andere IDE's zoals PHPStorm doen dat ook prima.

Patches mailen hoeft niet voor mij. Maar offline werken wel. Als ik op vakantie ga kan ik lekker door ontwikkelen op mijn laptop zonder dat ik dit naar een centrale repository hoeft te duwen. Dat kan wel weer als ik thuis bent. Ondertussen is alles wel netjes onderverdeeld in commits in plaats van de resulterende monster-commit als je het met SVN gedaan had.

Daarnaast heb ik ook diverse keren aan de Robocup wereldkampioenschappen meegedaan met een team, waarmee we werkten met Mercurial en later met Git. Aangezien de internetverbinding naar de buitenwereld op dergelijke evenementen in afgelegen oorden doorgaans uitermate belabberd is zetten we dan een lokale server op. Dat is heel simpel, je kloont de repository gewoon op een lokale laptop en start de SSH-server. Vervolgens kan het het hele team naar de lokale server pushen / pullen om met elkaar in sync te blijven. Op de schaarse momenten dat de internetverbinding dan wel werkte kon de beheerder van de lokale server pushen naar de 'hoofd'-repository zodat we ook met het thuisfront gesynchroniseerd konden blijven, daar waar dat nodig was. Een dergelijke aanpak is gewoon niet mogelijk met SVN of in het algemeen, met non-distributed versiebeheersystemen.

Offline branches zijn ook ideaal. Als ik of mijn collega's werken aan een bepaalde experimentele feature kunnen ze lokaal een nieuwe branch maken en daarmee werken. Wordt het niets dan wordt die branch nooit naar de centrale repository gepusht. Wordt het wel wat dan wordt de branch wel gepusht of gemerged met de master branch, waarbij je dus wel netjes de individuele commits hebt, en de mogelijkheid om te mergen met andere wijzigingen die in de tussentijd hebben plaatsgevonden.

[Reactie gewijzigd door MadEgg op 22 juli 2024 16:49]

[FragFrog]

Toevallig was mijn uni ook op de Robocup wedstrijden, en als er 1 ding was wat er in overdaad aanwezig was, was het wel een internetverbinding
En dat geldt voor toch wel heel erg veel vakantie-bestemmingen: zowat alle hotels die ik gezien heb in noord amerika en azie hadden prima gratis internet, idem voor zo ongeveer alle starbucks, McDonalds, etc. Again, we leven niet meer in 2005, internet is zo alomtegenwoordig tegenwoordig dat als "het werkt zonder internet" je hoofdargument is voor GIT, je voor 99.9% van de gebruikers geen arugment meer hebt. En zelfs als dat het wel is kun je prima offline patches maken in SVN, heb je geen internetverbinding voor nodig, voorkom je toch een monster-commit.

Het spijt me, ik blijf horen dat "GIT beter is want je kan alles offline doen!", van mensen die altijd online zijn en alleen maar committen naar GIThub. Mag natuurlijk, maar ik heb mezelf nooit betrapt op de gedachte "damn, ik heb net een week hard lopen coden op vakantie, en nu kan ik het niet committen omdat ik in centraal afrika sta!".

Aan de andere kant heb ik met GIT wel heel erg vaak gedacht "hoe de heck los ik de rebase problemen op tussen mijn offline branch en de master repo zonder mijn hele history kwijt te raken". En zo te horen meer mensen met mij.

[MadEgg]

Toevallig was mijn uni ook op de Robocup wedstrijden, en als er 1 ding was wat er in overdaad aanwezig was, was het wel een internetverbinding

Ik ben bij RoboCup in Eindhoven geweest, tweemaal, en daar was de verbinding prima. De stroomvoorziening liet het wel diverse malen afweten, maar dat terzijde Maar verder ben ik ook meerdere malen op RoboCup in Teheran, Instanbul, México, Magdeburg en Thailand geweest en op al die plekken was internet ofwel grotendeels afwezig ofwel zeer traag. Er viel niet mee te werken.

En dat geldt voor toch wel heel erg veel vakantie-bestemmingen: zowat alle hotels die ik gezien heb in noord amerika en azie hadden prima gratis internet, idem voor zo ongeveer alle starbucks, McDonalds, etc. Again, we leven niet meer in 2005, internet is zo alomtegenwoordig tegenwoordig dat als "het werkt zonder internet" je hoofdargument is voor GIT, je voor 99.9% van de gebruikers geen arugment meer hebt. En zelfs als dat het wel is kun je prima offline patches maken in SVN, heb je geen internetverbinding voor nodig, voorkom je toch een monster-commit.

Tja, ik elk jaar wel een week of twee in een huisje in de bergen in Frankrijk en daar is géén internet en ook geen 2G/3G/4G. Het zit er daar gewoon niet in. Als ik twee kilometer verderop op een heuveltje ga staan heb ik met wat moeite een 2G signaal maar dat voert wel wat ver om een commit te doen.

Het spijt me, ik blijf horen dat "GIT beter is want je kan alles offline doen!", van mensen die altijd online zijn en alleen maar committen naar GIThub. Mag natuurlijk, maar ik heb mezelf nooit betrapt op de gedachte "damn, ik heb net een week hard lopen coden op vakantie, en nu kan ik het niet committen omdat ik in centraal afrika sta!".

Dat mag. Of het waardevol voor je is mag je zelf bepalen natuurlijk. Ik gebruik het vaker dan jij lijkt te kunnen geloven, en dan ook in situaties die er echt om vragen. Daarnaast is zelfs als je alles naar Github pusht het ook handig om lokale commits, branches en tags te kunnen hebben zodat je commits kunt maken die de centrale repository niet vervuilen.

Daarnaast is een groot voordeel van git voor grotere projecten pull requests. Het repository forken op github is ideaal als je als niet core developer toch met de code aan de slag wilt. Je kunt dan je eigen commits in je eigen fork doen, en zodra alles af is en werkend kun je een pull request naar de core developers doen die het dan doodeenvoudig kunnen mergen zonder enige functionaliteit in te leveren en met volledig behoud van commit historie. Ook dat kun je niet met niet-distributed systemen als SVN. Natuurlijk kun je wel iets in die richting fabriceren door .patch bestanden te gaan rondsturen maar dat is wel weer een stap terug in gebruikersvriendelijkheid.

Aan de andere kant heb ik met GIT wel heel erg vaak gedacht "hoe de heck los ik de rebase problemen op tussen mijn offline branch en de master repo zonder mijn hele history kwijt te raken". En zo te horen meer mensen met mij.

Tja. Git heeft een leercurve. Het rebase-systeem moet je even onder de knie krijgen maar het is wel ideaal dát je de mogelijkheid hebt om geschiedenis te herschrijven als de situatie daarom vraagt. De commit-tree wordt ook veel schoner en overzichtelijker als je in plaats van merges rebases doet.

Ik beweer zeker niet dat git het summum van gebruikersvriendelijkheid is, en als je alleen push/pull doet en niet de moeite neemt om de geavanceerde functies onder de knie te krijgen dan kun je net zo goed SVN gebruiken. Doe je dat wel dan gaat er een wereld voor je open.

Hetzelfde geldt overigens voor Mercurial, daar hebben we ook een tijd mee gewerkt binnen het Robocup-team, en ook dat gaf dergelijke flexibilteit inherent aan een distributed versiebeheersysteem.

[Oljoner]

de manier waarop tags en branches 'geimplementeerd' zijn als shallow copies ipv first-class citizens zeer lelijk.

Wat bedoel je hier juist mee? (niet om je in twijfel te trekken)

[MadEgg]

SVN heeft geen notie van tags of branches. In ieder geval niet op het moment dat ik ermee opgehouden ben met werken. Het aanmaken van een branch ging als

svn cp https://example.com/svn/myrepo/trunk https://example.com/svn/myrepo/branches/my_new_branch

en een tag op dezelfde manier, maar dan naar svn/myrepo/tags/my_new_tag

Hiermee wordt een shallow kopie gemaakt; er wordt geen byte aan data gekopieerd op dat moment, maar er wordt wel een verwijzing naar de staat van de repository op dat moment gemaakt, in een andere plek in de bestandsstructuur.

Er is dan ook niets wat je verhinderd om 'branches' 'takken' te noemen, of 'trunk' als opslag voor je tags te gebruiken; het is volledig gebaseerd op conventie. Dat is vragen om slordigheden en bovendien maakt het het werken met tags en branches minder flexibel omdat het feitelijk bij SVN niet bekend is wat een tag of een branch is.

Het zou kunnen dat in de afgelopen jaren binnen SVN veranderd, maar dit was de stand van zaken een jaar of 5 geleden.

[Snow_King]

Ik vind SVN juist niet fijn omdat het altijd een server vereist, iets wat Git dus niet doet.

Zelf ben ik niet Git gaan gebruiken omdat Linus heet deed, maar omdat Git gewoon fijner werkt.

[RoestVrijStaal]

Uuhm nee? Je kan prima de SVN server proces lokaal op je machine draaien. On demand zelfs.

[AmazingDreams]

Dus er is altijd een server vereist.

[RoestVrijStaal]

Ik veronderstelde dat hij bedoelt dat een machine waarop het SVN server proces draait vereist is voor SVN

[OrangeTux]

Waar zit dat verschil in dat je Git prettiger vind voor applicaties en SVN voor websites?

[Blokker_1999]

Het belangrijkste verschil ontstaat wanneer je in groep gaat werken aan een project. Zolang je het individueel doet maakt het echt niet uit wat je gebruikt maar o.a. dankzij de manier van branching, merging en het feit dat je telkens zelf de volledige geschiendenis lokaal hebt staan maakt dat git enorm krachtig is binnen teams en wanneer je offline bent.

[YopY]

Het verschil zie je pas echt als je met meer dan 1 persoon gaat werken en dingen als vaker dan eens per dag committen, branches en tags wilt gaan doen.

[hsb85]

Als ik het goed lees is Git geschreven door Linus zodat ze niet meer afhankelijk waren van BitKeeper. Dus een concurrent was het toen zeker niet

[Snow_King]

Dat klopt, maar wie gaat BitKeeper nu nog gebruiken terwijl Git al zo veel wordt gebruikt. Daarom lijkt de zet van BitKeeper mij kansloos.

[MadEgg]

Op de Why-pagina staat uitgelegd waarom je eventueel voor BitKeeper zou kunnen kiezen. Ze geven zelf ook duidelijk aan dat Git in veel gevallen een beter alternatief is maar dat BitKeeper soms misschien handiger is als je waarde hecht aan, volgens hun, meer data over wijzigingen, betere omgang met submodules en betere omgang met grote binaire bestanden zoals foto's en video's.

Zelf geen ervaring met BK maar heb iig wel vaker problemen gehad met submodules en binaire bestanden in git. Het kan wel, er zijn hier en daar nog addons voor om het beter te laten werken maar helemaal ideaal is het niet. Misschien dat het in sommige gevallen dan inderdaad handiger is om BitKeeper te gebruiken.

[Zezura]

Git heeft tegenwoordig git LFS en dat is een geweldige toevoeging voor goede ondersteuning van Binaire files.

[MadEgg]

Niet echt. Git heeft geen LFS. Github heeft LFS. LFS is een toevoeging van Github, die ook een LFS server vereist.

Het grootste deel van de repositories waar ik mee werk zijn niet op Github dus dat betekent een hoop extra werk om de boel aan de slag te krijgen.

[update]
Ik heb in het verleden wel eens gewerkt met git annex. Dat is een veel betere implementatie IMO aangezien je daarmee niet vast zit aan een centrale server, maar in plaats daarvan P2P kunt synchroniseren. Je kunt zelf één of meerdere repositories hebben en die kun je op wat voor manier dan ook met elkaar delen; via internet / ssh, maar ook door het gewoon op een USB-stick te zetten en aan iemand mee te geven.

Git LFS is sterk gekoppeld aan github, zo te zien. Met wat rare sprongen kun je wel een eigen server draaien, maar ook dan zit je aan een centrale server vast. Wmb dus geen goede oplossing die de pluspunten van git behoudt.

De perfecte oplossing ziet er wmb nog net iets anders uit, waarbij binaire blobs rechtstreeks door GIT beheerd worden, maar dan zonder diffs / historie. Bij een sync download je alleen de actuele versie van de bestanden, en het verwijderen van outdated bestanden zou ook veel eenvoudiger moeten worden. Het kan leuk zijn om wat historie te hebben / oude versies te kunnen opvragen, maar in veel gevallen is dat absoluut niet nodig. Hierdoor explodeert de grootte van de repository niet, en behoud je alle voordelen van git.

[Reactie gewijzigd door MadEgg op 22 juli 2024 16:49]

[Rafe]

GitLab (zowel CE als EE) doet LFS sinds versie 8.2. Git-annex moet je nog steeds EE voor kopen.

De ontwikkeling van LFS er van wordt wel aangejaagd vanuit GitHub inderdaad.

[MadEgg]

Vrijwel alle repositories waar ik mee werk draaien op een VPS en worden beheerd mbv gitolite. Daar hoeft niets voor aangeschaf te worden, alles is volledig gratis te gebruiken. Git annex is ook niet afhankelijk van support van de repository waar je naartoe pusht. Git annex synchroniseert met 'git-annex-repositories', waar je op wat voor manier dan ook toegang toe kunt krijgen. Bijvoorbeeld door een USB-stick in je PC te stoppen. Of een DVD. Of via SSH verbinding te maken met een server.

[P1nGu1n]

Correctie: Git is ontwikkeld door diverse Linux kernel developers, waaronder Linus Torvalds. Inderdaad om niet meer afhankelijk te zijn van BitKeeper.

[Reactie gewijzigd door P1nGu1n op 22 juli 2024 16:49]

[Blokker_1999]

Ik dacht dat Git (het protocol) toch echt door Linus is ontwikkeld en dat later andere mensen alle tools er rond hebben gebouwd zoals we die vandaag kennen.

[VoDkA12]

Ja, helemaal gezien ze Git & Github gebruiken ....

https://github.com/bitkeeper-scm/bitkeeper
Om te gebruiken, voer je uit:
git clone https://github.com/bitkeeper-scm/bitkeeper.git

[Reactie gewijzigd door VoDkA12 op 22 juli 2024 16:49]

[Rafe]

Dat is een mirror, zoals ook in de beschrijvende tekst van de repo staat. Daar zien ze daar de ironie ook wel van in

Clone with BitKeeper
bk clone bk://bkbits.net/u/bk/bugfix (or 'dev' for the latest)

Clone with git
Yes you heathens can clone the last released version of BitKeeper from github.com with the following command:
git clone https://github.com/bitkeeper-scm/bitkeeper.git

OpenBSD gebruikt nog CVS voor versiebeheer en heeft bijvoorbeeld ook een onofficiele git mirror.

[VoDkA12]

Ohhhhh, niet gezien Dacht al dat het vreemd was. Neem aan dat elke versiebeheersystem het doel heeft om 'self hosting' te zijn.

Maar Github als mirror is logisch.

[Treenaks]

https://lwn.net/Articles/130746/ en https://lwn.net/Articles/132938/ voor wat achtergrond over "het einde van BitKeeper voor de Linux-kernel"

[Reactie gewijzigd door Treenaks op 22 juli 2024 16:49]

[Steef435]

Ik kan niet anders dan denken dat dit tien jaar te laat is, in ieder geval wat de FOSS wereld betreft. Er zijn al genoeg opties en ik denk niet dat iemand zin heeft om de boel nog meer te fragmenteren.

[Jerie]

The grand irony is that Larry was one of the earliest advocates of open sourcing the operating system at Sun [...] door Bryan Cantrill (voormalig collega van Larry McVoy bij Sun)

What are some well-written accounts of the Linux-Bitkeeper-Git story? door Oscar Bonilla (core BitKeeper developer)

[Reactie gewijzigd door Jerie op 22 juli 2024 16:49]