There is an official mirror on GitHub: https://github.com/bitkeeper-scm/bitkeeper
It's a read only mirror, the read/write mirror is on bkbits.net. But we'll maintain the mirror (or you can, bk has fast-export which creates a perfect mirror in git).
Show HN: BitKeeper – Enterprise-ready version control, now open-source
151–160 of 309 posts
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#152Interesting — FreeBSD 7 and 8 binaries available for download. Neither of those is a current supported release. It's like offering RHEL 3 or 4 binaries.
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#153Earlier quoted context omitted.
In short, RCS maintains a clean copy of the head revision, and a set of reverse patches to be applied to recreate older revisions. SCCS maintains a sequence of blocks of lines that were added or deleted at the same time, and any revision can be extracted in the same amount of time by scanning the blocks and retaining those that are pertinent. Really old school revision control systems, like CDC's MODIFY and Cray's cl…
| CDC's MODIFY and Cray's clone UPDATE, were kind of like SCCS Do you have references? I've heard of these but haven't come across details after much creative searching since they are common words.
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#154Earlier quoted context omitted.
Presumably if you then delete that first line in the third version, you get something like ^AI 1 this is the first line in the first version. ^AE 1 ^AD 3 ^AI 2 this is the line that was added in the second version ^AE 2 ?
Close. By the way there is a bk _scat command (sccs cat, not poop) that dumps the ascii file format so you can try this and see. The delete needs to be an envelope around the insert so you get ^AD 3 ^AI 1 this is the first line in the first version. ^AE 1 ^AE 3 ^AI 2 this is the line that was added in the second version ^AE 2 That whole weave thing is really cool. The only person outside of BK land that got it was Br…
^AI 1..2
this is the first line in the first version.
^AE 1..2
^AI 2
this is the line that was added in the second version
^AE 2
This way the reconstruction process wouldn't need to track blocks-within-blocks.Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#155Earlier quoted context omitted.
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…
My $0.02 canadian; Build something that kicks Gitlab and Github's ass. What an opportunity. Support both BK and GIT repos. Provide a distributed workflow that enterprises will love. Enterprises are obviously where the remaining dollars are. There are billions of dollars of inefficiencies in that sector. Many of these enterprises do NOT want to host their code on Github and are buying Gitlab. Be better than Gitlab.
Bitbucket has been rotting since Atlassian bought them, and now there's really no "killer app" for Mercurial hosting. There are Mercurial hosting services out there, but nothing anywhere close to Github/Gitlab.
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#156Earlier quoted context omitted.
Are you aware of any hosting solutions that support BK as-is? eg something like Gogs or similar Asking due to looking for a Gogs/GitLab (like) server side solution for a project under development. However, it needs to handle binary data well, which Git-based solutions don't.
We've got a very primitive hosting service up at bkbits.net. One of the ways we hope to survive is to evolve that into something closer to Github.
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#157Earlier quoted context omitted.
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…
My $0.02 canadian; Build something that kicks Gitlab and Github's ass. What an opportunity. Support both BK and GIT repos. Provide a distributed workflow that enterprises will love. Enterprises are obviously where the remaining dollars are. There are billions of dollars of inefficiencies in that sector. Many of these enterprises do NOT want to host their code on Github and are buying Gitlab. Be better than Gitlab.
I haven't checked out Bitbucket because last time I evaluated (2+ years ago) they didn't have good on-prem options.
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#158Earlier quoted context omitted.
The NSE was Suns attempt at a grand SCM system and it was miserably slow (single threaded fuse like COW file system implemented in user space). I did performance work back then, sort of a jack of all trades (filesystem, vm system, networking, you name it) so Sun asked me to look at it. I did and recoiled in horror, it wasn't well thought out for performance. My buddies in the kernel group were actually starting to qu…
There used to be a paper on smoosh here: http://www.bitmover.com/lm/papers/smoosh.ps but it's gone now. Do you mind putting it back? I'd like to read it again.
Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source
#159I have some questions about Why.html: https://www.bitkeeper.org/why.html > Spending a lot of time dealing with manual and bad auto-merges? BitKeeper merges better than most other tools, and you will quickly develop confidence in the quality of the merges, meaning no more reviewing auto-merged code. Do you have examples of merge-scenarios that are a Conflict for git but resolve for BK? > BitKeeper’s raw speed for larg…
Wayne pointed to some stuff over on the reddit thread. As for size it's csets * files, as that gets big, Git slows down faster than linear, we're pretty linear.