[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BitKeeper open-sourced
Give it a try.
> On Jun 5, 2016, at 5:23 AM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> BitKeeper is now released as APL-2.0. https://www.bitkeeper.org/
> From the webpage:
> BitKeeper is the original distributed source management system. Now
> available as Open Source under the Apache 2.0 License.
> BitKeeper is a fast, enterprise-ready, distributed SCM that scales up to
> very large projects and down to tiny ones.
> - Simple: An easy to use command line interface.
> - Scalable: Nested Repositories are submodules done right! Version
> control collections of repositories.
> - Flexible: Hybrid mode for binary files that uses a cloud of
> server for binaries instead of bloating the source repositories.
> - Accurate: Tracking of file operations like creates, deletes, and
> - Safe: All file accesses validate checksums for integrity. All
> file writes include redundancy for error correction.
> - Dependable: Highly accurate auto-merge that uses the whole
> history to resolve conflicts. Most other systems use variations
> of diff3.
> - Discernable: Source annotations instantly available.
> - Fast: High performance and scales to very large repositories.
> - Free: Licensed under the Apache Version 2 license
> It matches the requirements of David Holland from "preliminary version
> control requirements" , except branching -- as branches are handled
> as separate clones. According to the upstream developers it should work
> well for releng.
> There is a fallback for restricted environment to pull the changes from
> a remote repository and more or less (according to my understanding)
> apply binary diff from upstream tarball to the checkout (according to
> upstream show work pretty fine with 64MB RAM).
> Performance comparisons with git are pretty promising, p. 5:
> BitKeeper currently depends on PCRE and TCL/TK, but at least the TCL/TK
> requirement is going to be detached and bitkeeper-base-like package will
> depend on C. There are more dependencies bundled in and they are in
> process of unloading.
> The code is NetBSD friendly, upstream used our source-code (notably
> stdio from libc) for portability reasons.
> There is strong upstream commercial support for BK and the product isn't
> going anywhere.
> I hope It shouldn't be too difficult to get help from upstream with
> proper CVS->BK conversion.
>  http://mail-index.netbsd.org/tech-repository/2008/07/26/msg000003.html
Main Index |
Thread Index |