Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to BitKeeper.
Nothing was collected or created yet.
BitKeeper
View on Wikipediafrom Wikipedia
| BitKeeper | |
|---|---|
 | |
| Original author | BitMover Inc. |
| Initial release | May 4, 2000 |
| Final release | 7.3.3
/ December 29, 2018[1] |
| Repository | |
| Written in | C |
| Operating system | AIX, FreeBSD, HP-UX, IRIX, Linux, Mac OS X, NetBSD, OpenBSD, Solaris, Windows |
| Type | Distributed revision control |
| License | 2016: Apache-2.0[a] 2000: Proprietary[b] |
| Website | www |
BitKeeper is a discontinued software tool for distributed revision control of computer source code. Originally developed as proprietary software by BitMover Inc., a privately held company based in Los Gatos, California,[2] it was released as open-source software under the Apache-2.0 license on 9 May 2016.[3] BitKeeper is no longer being developed.[4][5]
History
[edit]BitKeeper was originally developed by BitMover Inc., a privately held company from Los Gatos, California owned by Larry McVoy, who had previously designed TeamWare.[6]
BitKeeper and the Linux kernel
[edit]BitKeeper was first mentioned as a solution to some of the growing pains that Linux was having in September 1998.[7] Early access betas were available in May 1999[8] and on May 4, 2000, the first public release of BitKeeper was made available.[9][10] BitMover used to provide access to the system for certain open-source or free-software projects, one of which was the source code of the Linux kernel. The license for the "community" version of BitKeeper had allowed for developers to use the tool at no cost for open source or free software projects, provided those developers did not participate in the development of a competing tool (such as Concurrent Versions System, GNU arch, Subversion or ClearCase) for the duration of their usage of BitKeeper. This restriction applied regardless of whether the competing tool was free or proprietary. This version of BitKeeper also required that certain meta-information about changes be stored on computer servers operated by BitMover, an addition that made it impossible for community version users to run projects of which BitMover was unaware.
The decision made in 2002 to use BitKeeper for Linux kernel development was a controversial one. Some, including GNU Project founder Richard Stallman, expressed concern about proprietary tools being used on a flagship free project. While project leader Linus Torvalds and other core developers adopted BitKeeper, several key developers (including Linux veteran Alan Cox) refused to do so, citing the BitMover license, and voicing concern that the project was ceding some control to a proprietary developer. To mitigate these concerns, BitMover added gateways which allowed limited interoperation between the Linux BitKeeper servers (maintained by BitMover) and developers using CVS and Subversion. Even after this addition, flamewars occasionally broke out on the Linux kernel mailing list, often involving key kernel developers and BitMover's CEO Larry McVoy, who was also a Linux contributor.[11][original research?]
In April 2005, BitMover announced that it would stop providing a version of BitKeeper free of charge to the community, giving as the reason the efforts of Andrew Tridgell, a developer employed by OSDL on an unrelated project, to develop a client which would show the metadata (data about revisions, possibly including differences between versions) instead of only the most recent version. Being able to see metadata and compare past versions is one of the core features of all version-control systems, but was not available to anyone without a commercial BitKeeper license, significantly inconveniencing most Linux kernel developers. Although BitMover decided to provide free commercial BitKeeper licenses to some kernel developers, it refused to give or sell licenses to anyone employed by OSDL, including Linus Torvalds and Andrew Morton, placing OSDL developers in the same position as other kernel developers. The Git project was launched with the intent of becoming the Linux kernel's source code management software, and was eventually adopted by Linux developers.
End of support for the "Free Use" version of BitKeeper was officially July 1, 2005, and users were required to switch to the commercial version or change version control system by then. Commercial users were also required not to produce any competing tools: In October 2005, McVoy contacted a customer using commercially licensed BitKeeper, demanding that an employee of the customer stop contributing to the Mercurial project, a GPL source management tool. Bryan O'Sullivan, the employee, responded, "To avoid any possible perception of conflict, I have volunteered to Larry that as long as I continue to use the commercial version of BitKeeper, I will not contribute to the development of Mercurial."[12]
Move to open-source
[edit]During the release of version 7.2ce at May 9, 2016, BitKeeper announced that it is starting to move from a proprietary to an open-source license,[13] eventually releasing the software under the Apache License version 2.
See also
[edit]Notes
[edit]References
[edit]- ^ "BitKeeper version 7.3.3 released Dec 29 2018". 9 February 2019.
- ^ "Company information". BitMover. Archived from the original on 2016-08-01. Retrieved 2016-07-13.
- ^ "BitKeeper". Archived from the original on 2016-05-10. Retrieved 2016-05-10.
- ^ "BitKeeper community forum". BitMover. 31 December 2019. Retrieved 2020-05-06.
- ^ "Contributors to bitkeeper". GitHub. Retrieved 2021-04-30.
- ^ "Company information". BitMover. Archived from the original on 2016-08-01. Retrieved 2016-07-13.
- ^ McVoy, Larry (30 Sep 1998). "A solution for growing pains". linux-kernel (Mailing list).
- ^ "Current status". BitMover. 1999. Archived from the original on 1999-05-08.
- ^ "Current status". BitMover. 4 May 2000. Archived from the original on 2000-06-17.
- ^ "Development projects". LWN.net. 11 May 2000.
- ^ Stallman, Richard (13 October 2002). "Bitkeeper outragem, old and new". linux-kernel (Mailing list). Retrieved 23 August 2019 – via MARC.
- ^ O'Sullivan, Bryan (30 September 2005). "Why I am no longer working on Mercurial". mercurial-devel (Mailing list). Archived from the original on 29 September 2007. Retrieved 14 April 2007.
- ^ "BitKeeper announces opensource license ahead". BitKeeper.org. 9 May 2016.
External links
[edit]
Years, where available, indicate the date of first stable release. Systems with names in italics are no longer maintained or have planned end-of-life dates. | ||||||
| Local only |
|  | ||||
| Client–server |
| |||||
| Distributed |
| |||||
| Concepts | ||||||
BitKeeper
View on Grokipediafrom Grokipedia
BitKeeper is a distributed source code management system originally developed as proprietary software by BitMover, Inc., and later released as open source under the Apache 2.0 License.[1]
Created by Larry McVoy to address limitations in traditional centralized version control tools like CVS, it emphasizes speed, scalability for large projects, and features such as local commits, changeset-based push/pull operations, and high auto-merge success rates exceeding 95 percent.[2][3]
In 2002, Linux kernel maintainer Linus Torvalds adopted BitKeeper for kernel development, replacing inefficient manual patch workflows with distributed collaboration that saved developers hours weekly and enabled peer-to-peer synchronization across global teams.[3][4]
The system's proprietary nature and usage restrictions, including prohibitions on developing competing tools, sparked ongoing community debate, culminating in 2005 when reverse-engineering efforts by developer Andrew Tridgell violated its license terms, prompting BitMover to revoke free access for non-commercial kernel contributors.[4]
This dispute accelerated the creation of Git by Torvalds as a free alternative, though BitKeeper's distributed architecture influenced modern revision control systems; it remains available today as an enterprise-hardened open source tool.[4][1]
Origins and Early Development
Founding of BitMover and Initial Design
BitMover, Inc., a software company specializing in source code management tools, was founded in 1998 by Larry McVoy, a veteran engineer previously employed at Sun Microsystems where he contributed to the development of TeamWare, an early distributed revision control system built atop SCCS.[5] McVoy established BitMover as a privately held entity in Silicon Valley to commercialize advanced version control technologies, drawing from his extensive experience in operating systems, networking, and scalable software tools since the late 1980s.[6] [7] Development of BitKeeper, BitMover's flagship product, commenced in 1998 under McVoy's direction, motivated by the shortcomings of centralized systems like CVS, which struggled with scalability for large, distributed projects such as the Linux kernel.[5] McVoy initially sketched BitKeeper's concepts on the Linux Kernel Mailing List that year, emphasizing a distributed model that enabled developers to work offline with full repository functionality, including branching, merging, and change tracking without constant server dependency.[8] The design prioritized efficiency through packed delta compression for storage, changeset-oriented commits to capture atomic changes, and robust networking protocols for synchronization, aiming to support massive codebases while minimizing bandwidth and computational overhead compared to file-by-file differencing in prior tools.[9] BitKeeper's initial version was released on May 4, 2000, as proprietary software with a freemium model offering gratis access for open-source and non-commercial use to encourage adoption, while charging enterprises for support and advanced features.[10] This approach reflected McVoy's intent to innovate beyond Sun's TeamWare limitations, incorporating lessons from real-world distributed development needs, such as those encountered in kernel subsystems testing by late 1999.[11] Early prototypes demonstrated superior performance in handling nonlinear histories and concurrent contributions, setting the stage for its later integration into high-profile projects.[12]Key Innovations in Distributed Version Control
BitKeeper introduced several pioneering features to distributed version control systems (DVCS), emphasizing decentralization, efficiency, and scalability for large-scale collaborative development, such as the Linux kernel project starting in 2002.[3] Unlike centralized systems like CVS, which required constant server connectivity and limited offline work, BitKeeper enabled every developer to maintain a complete, functional repository clone, supporting independent operations like committing, branching, and merging without a central authority.[13] This peer-to-peer model facilitated asynchronous collaboration across distributed teams, with changes propagated via pull and push commands that transmitted only deltas rather than full histories, reducing bandwidth needs.[3] A core innovation was the change set abstraction, treating commits as atomic, self-contained units identifiable by cryptographic hashes, which could be emailed, reviewed, or exchanged as "super-patches" encompassing multiple files and metadata.[8] This allowed precise tracking and application of changes without relying on linear patch sequences, enabling non-linear workflows and reducing merge conflicts in branched development. BitKeeper's change sets included full provenance, supporting reproducible builds and auditability, which proved effective for the kernel's high-velocity, multi-contributor environment.[3] BitKeeper advanced merging capabilities beyond traditional three-way diffs by leveraging the entire revision history for context-aware resolution, achieving higher auto-merge accuracy and minimizing manual intervention.[14] It natively detected and tracked file renames, moves, and deletes across changesets, preserving semantic history that simplistic tools often lost, thus supporting complex refactorings in large codebases.[13] For performance, the system employed optimized delta compression and redundant encoding for data integrity, with checksum validation on access, enabling fast clones and pushes even for repositories exceeding millions of lines, as demonstrated in kernel-scale usage.[14] Additionally, features like nested repositories (BK/Nested) allowed scalable management of monolithic projects by subdividing into interdependent sub-repos with automatic synchronization of changesets and configurations.[15] These innovations prioritized causal integrity and empirical efficiency over simplistic models, influencing subsequent DVCS like Git, though BitKeeper's proprietary origins limited broader adoption until its 2016 open-sourcing.[13] Larry McVoy, BitKeeper's designer, drew from prior systems like Sun's TeamWare but emphasized DVCS-specific solutions for real-world scalability, validated through production use rather than theoretical ideals.[3]Technical Features and Architecture
Core Mechanisms and Capabilities
BitKeeper functions as a distributed version control system, enabling developers to maintain independent local repositories that synchronize through peer-to-peer operations without requiring constant connectivity to a central server.[3] Changesets serve as the fundamental unit of change, grouping related deltas across multiple files into atomic, logical bundles that include metadata such as commit comments and serve as synchronization anchors, allowing precise reproduction of repository states at any point.[3] Developers commit changes locally usingbk ci for individual files and bk commit to form and record a changeset, which captures the modifications while preserving the full tree state for tagging and branching.[3]
Synchronization relies on bk pull to fetch unshared changesets from a remote repository and bk push to transmit local ones, with the system transferring only differential data to minimize bandwidth; merging occurs after pulling, leveraging automated algorithms that resolve approximately 95% of conflicts without manual intervention.[3] Cloning via bk clone optimizes storage by hard-linking files within the same filesystem, supporting multiple lightweight clones (typically 5-50 per developer) that share disk space efficiently while allowing independent evolution.[3] File handling assigns unique identifiers to track renames and moves (e.g., via bk mv), maintains permissions and attributes, and employs redundant encoding with checksums to detect and correct filesystem or hardware errors, ensuring data integrity across distributed environments.[14][3]
Key capabilities include scalability for large-scale projects through nested repositories, which version-control collections of sub-repositories and synchronize changesets across them, accommodating thousands of files and global developer teams as demonstrated in Linux kernel workflows.[14][3] For binaries and large assets, the Binary Asset Manager (BAM) provides decentralized local storage, avoiding full historical versioning of oversized files (e.g., videos or CAD models) by referencing hashes and enabling fast, resource-efficient access without centralization.[14] Additional features support subset sharing for secure partial code distribution to teams and total build reproducibility by tying changesets to verifiable states, reducing merge conflicts and administrative overhead in non-linear development.[14]
Performance and Scalability Advantages
BitKeeper exhibited notable performance advantages in managing large repositories, with its developers claiming raw operational speeds superior to competing systems, particularly for remote collaborations, handling large binary assets, and operations over network file systems like NFS.[14] This efficiency stemmed from its distributed architecture, which minimized overhead in common commercial workflows, enabling faster check-ins, check-outs, and history traversals compared to centralized tools like CVS.[16] In practice, its adoption by the Linux kernel project from 2002 onward facilitated rapid development cycles, supporting contributions from hundreds of developers without the bottlenecks seen in prior email-based patch systems.[17] Scalability was enhanced through features like database replication, ensuring optimal performance for both local and remote users by distributing load across mirrors, which avoided single points of failure and latency issues in high-traffic environments.[16] A key innovation, BitKeeper Nested (BK/Nested), allowed decomposition of monolithic repositories into logical sub-repositories—such as separating source code, documentation, and libraries—while maintaining synchronized changesets and atomic commits.[15] This approach enabled sparse cloning of subsets, circumventing performance degradation in massive codebases exceeding 4 million changesets, 1 million files, or 9.5 GB, as full clones would otherwise overwhelm storage, compute, and network resources.[15] By preserving distributed workflows without introducing signal-to-noise dilution, BK/Nested supported scaling to enterprise-level projects far beyond typical open-source repositories.[14] Additionally, the Binary Asset Manager (BAM) optimized handling of large binaries by enabling local storage references rather than embedding them fully, preserving repository speed and resource efficiency in media-heavy or embedded projects.[14] These mechanisms collectively contributed to BitKeeper's robustness in the Linux kernel's 2.6 series development, where maintainers credited it with achieving unprecedented capability and scalability for a distributed team.[17]Adoption in Open Source Projects
Integration with Linux Kernel Development
BitKeeper's adoption by the Linux kernel project began in February 2002, when Linus Torvalds integrated it into the development workflow for the 2.5 kernel series, marking a shift from manual patch emailing to distributed version control.[18][4] Prior to this, from 1991 to 2002, contributors emailed diffs to Torvalds, who reviewed and applied them manually to a central tree, a process that scaled poorly as the codebase and developer base grew beyond 1,000 contributors.[8][19] Torvalds selected BitKeeper, developed by BitMover Inc. under Larry McVoy, for its proprietary but freely licensed access to open-source projects, despite opposition from figures like Richard Stallman over its non-free nature.[4] The integration transformed kernel development into a pull-based model, where developers cloned Torvalds' repository usingbk clone, pulled updates with bk pull to synchronize local trees, developed features or fixes in branches, and prepared changes for upstream integration.[20][21] Subsystem maintainers and architecture teams maintained semi-independent repositories, enabling parallel work on drivers, filesystems, and ports without constant central coordination; Torvalds then pulled vetted changes via bk pull from trusted public trees, reducing email overhead and merge conflicts through BitKeeper's efficient delta storage and three-way merge capabilities.[22][3] This distributed approach supported non-linear development, with lightweight branching via bk new and bk parent, allowing rapid experimentation and integration across geographically dispersed contributors.[4]
BitKeeper's performance advantages, including change-set tracking and weave-based file storage, handled the kernel's multimillion-line codebase efficiently, with operations like pulls completing in seconds even over slow links, outperforming tools like CVS in scalability for large, active projects.[3][21] By enabling verifiable change provenance and atomic commits, it minimized integration errors, fostering trust in merges; for instance, the system logged metadata on who introduced changes, aiding debugging.[22] This workflow persisted through kernel versions 2.5 and into 2.6 releases until April 2005, when access restrictions ended its role, having facilitated thousands of contributions and streamlined development for over three years.[17][19]