Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: BitKeeper – Enterprise-ready version control, now open-source

bitkeeper.org

Post reply on HN
Print view View original

131–140 of 309 posts

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#131

Post by luckydude »

Jare wrote: post #114
luckydude wrote: post #31

Earlier quoted context omitted.

Yes. Binaries are handled by one or more servers, we call them BAM servers. The servers hold the data and your repo holds the meta data, binaries are fetched on demand. You can have a cloud of servers so the binaries are "close" (think China, India, US).

Two questions: It is unclear to me if the BAM server is part of this opensourcing or not. The page talks about a 90-day trial. Also, it is common in other (usually non-D)VCS workflows to lock binary files while working on them, since concurrent changes can't be merged the way text files allow. Does BK support anything like this?

We open sourced everything. So yes, it's there. The commercial site is out of date.

We have not done the centralized lock manager, we didn't get commercial demand for that (yeah, surprised me too). We could do it though, it's not that hard.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#132

Post by luckydude »

paulasmuth wrote: post #74

The nested repository feature sounds amazing. Dealing with both git submodules and git subtrees has been a huge pain for me. I'm looking forward to trying this out over the weekend. Is there some kind of util/script to import history from git?

Working on getting a crappy one out there, we have simple and pretty crappy and complex / fragile but less crappy.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#133

Post by justinclift »

sytse wrote: post #128
justinclift wrote: post #121

Earlier 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.

Consider using Git LFS for binary data, our GitLab.com supports it up to 10GB per project, self hosted installations are limited only by the disk volume.

Yeah, it's a possibility. Just hoping for something better. :)

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#134

Post by luckydude »

caf wrote: post #129
luckydude wrote: post #50

Earlier quoted context omitted.

RCS is patch based, the most recent version is kept in clear text and the previous version is stored as a reverse patch and so on back to the first version. So getting the most recent version could be fast (it isn't) but the farther back you go in history the more time it takes. And branches are even worse, you have to patch backwards to the branch point and then forwards to the tip of the branch. SCCS is a "weave".…

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 Braam Cohen in Codeville, I think he had a weave.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#135

Post by luckydude »

justinclift wrote: post #121
luckydude wrote: post #66

Earlier quoted context omitted.

Try it and let us know. You can download the binaries at bitkeeper.org and then clone the repo like so: $ bk clone http://bkbits.net/u/bk/bugfix/ type make and you should have a working BK built from source.

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

#136

Post by canadiangeek2 »

luckydude wrote: post #32
to3m wrote: post #18

1 year ago: https://news.ycombinator.com/item?id=9330482 What changed? Is BitKeeper still an ongoing business with some other model, or is that, as they say... it? I hope not.

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.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#137

Post by luckydude »

danielbot wrote: post #122
luckydude wrote: post #52

Earlier quoted context omitted.

Each history file contains it's internal name, much like a file system has an inode # that is the internal name for that file. We call the names "keys" and you can dig out the inode key like so (every delta has a key, the first delta is called the rootkey): $ bk log -nd:ROOTKEY: -r+ slib.c lm@bitmover.com|src/slib.c|19970518232928|52808|f3733b2c327712e5 The key is user@host|relative path|UTC|checksum|64 bits of /dev/…

Not tracking namespace accurately is Git's biggest weakness and would most probably be BK's best argument for getting a tryout. With Git, renaming a file and editing it at the same time tends to make a mess of the history and cause much pain. You can say just don't do that, but I say it happens, and it should just work.

That and a UI that is uniform and sub-modules that work correctly and a system that doesn't let you do things that mess up your data. Oh and blame that is fast:

  $ time bk annotate slib.c | wc -l
  18508

  real    0m0.031s

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#138

Post by jeremycole »

Huh. Thanks for doing this. As a MySQL employee in the early days I used BitKeeper and fell in love with it and kept using it as long as I could. I mainly use Git these days, but frequently miss BitKeeper -- BK felt a lot more natural to me than Git ever has.

Re: Show HN: BitKeeper – Enterprise-ready version control, now open-source

#140

Post by luckydude »

jeremycole wrote: post #138

Huh. Thanks for doing this. As a MySQL employee in the early days I used BitKeeper and fell in love with it and kept using it as long as I could. I mainly use Git these days, but frequently miss BitKeeper -- BK felt a lot more natural to me than Git ever has.

Hey Jeremy, long time no talk. We have the MySQL 6.x tree in BK, we can put up on bkbits if you like.
Post reply on HN