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

71–80 of 309 posts

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

#71

Post by nostrademons »

luckydude wrote: post #58
appleflaxen wrote: post #54

Earlier quoted context omitted.

Thanks for providing this level of detail; it's interesting to see the considerations that went into your decision. How / why did you decide to use the Apache license rather than the GPL? (It seems like a viral license might protect you a little bit, if you want to prevent your competitors from forking and improving your code base and then using it to compete against you.)

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 :) As to why that license, I think it was because LLVM or clang or both had recently…

(Apache2 has a number of explicit clauses that make it preferable for open-sourcing commercial software. For example, it automatically grants a patent license for any patents used by the software, but then terminates that license if a licensee sues over that software only [as opposed to React's original patent clause, which could be construed as terminating the license if you sue Facebook at all and got them into a lot of trouble], so that contributors can include patches covered under their patents without poisoning it for everyone. It also defines that all contributions are licensed under Apache2 as well, so that if you take patches and then incorporate them into your commercial software, the contributor can't turn around and sue you for them. And it's GPL3-compatible, which many other permissive licenses aren't.)

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

#72

Post by drostie »

jordigh wrote: post #26
dsr_ wrote: post #9

For people who don't know the history -- McVoy offered free bitkeeper licenses to various open source projects, and the Linux kernel switched to it. After Andrew Tridgell (SAMBA, among other projects) reverse-engineered the bitkeeper protocol [1] in order to create his own client, the license was rescinded for everyone. As a result, Linus wrote git. [1] https://lwn.net/Articles/132938/

> As a result, Linus wrote git. And mpm wrote hg, never forget: http://lkml.iu.edu/hypermail/linux/kernel/0504.2/0670.html http://lwn.net/Articles/151624/

It's astonishing to me that Git has won out given how much easier it's been for me to explain Hg to other people than to explain Git. To this day, in our SVN workflow at my company, nontechnical people who have merely seen a Hg diagram on a whiteboard by my desk immediately grasped the idea and the lingo, and ask me questions like "hey, can you branch the code to commit those changes and push them to the testing server? This thing's really cool and we don't mind playing with the alpha version, but we might scrap it all later."

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

#73

Post by ob »

drewg123 wrote: post #68

Can it import from git or SVN or mercurial? Looking at the bk import man page, it looks like it cannot import from any modern VCS. I see only RCS, SCCS, CVS, and MKS as options. This is unfortunate, as I have a mercurial tree I'd like to import.

We have a git importer but it's not part of the "official" repo as there are still a few corner cases. I am afraid we don't have a mercurial importer though...

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

#74

Post by paulasmuth »

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?

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

#75

Post by nickpsecurity »

rbanffy wrote: post #47
luckydude wrote: post #41

Earlier quoted context omitted.

Yeah this irony is not lost on me. But in both cases, the companies acted in self interest. Neither had the guts to walk away from their existing revenue stream. It's hard to say what would have happened. It's been an interesting ride and if nothing else, BK was the inspiration for Git and Hg, that's a contribution to the field. And maybe, just maybe, people will look at the SCCS weave and realize that Tichy pulled t…

> the companies acted in self interest Sun, could, at least, make a profit building workstations and servers and licensing chips. It's actually very sad they don't build those SPARC desktops anymore.

I really doubt it. There's not enough demand to make them competitive in price-performance. The server chips have stayed badass but still niche market. There's even open-source, SPARC HW with reference boards for sell from Gaisler. That didn't take off.

I liked the desktops but there's no money in them. Market always rejects it. So does FOSS despite it being the only open ISA with mainstream, high-performance implementations.

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

#76

Post by DonHopkins »

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…

A South Park reference, ehe?

Well clearly in retrospect, step two should have been renaming it "Dawson's Creek Trapper Keeper Ultra Keeper Futura S 2000" [1], adding incredibly advanced computerized features including a television, a music player with voice recognition, OnStar and the ability to automatically hybrid itself to any electronic peripheral device, absorbing the secret military computer at Cheyenne Mountain, and taking over the world.

[1] https://en.wikipedia.org/wiki/Trapper_Keeper_(South_Park)

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

#77

Post by nickpsecurity »

drostie wrote: post #72
jordigh wrote: post #26

Earlier quoted context omitted.

> As a result, Linus wrote git. And mpm wrote hg, never forget: http://lkml.iu.edu/hypermail/linux/kernel/0504.2/0670.html http://lwn.net/Articles/151624/

It's astonishing to me that Git has won out given how much easier it's been for me to explain Hg to other people than to explain Git. To this day, in our SVN workflow at my company, nontechnical people who have merely seen a Hg diagram on a whiteboard by my desk immediately grasped the idea and the lingo, and ask me questions like "hey, can you branch the code to commit those changes and push them to the testing serv…

This applied to me as well. I like the metaphor someone wrote that Git is the assembly language of DCVS.

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

#78

Post by civilian »

I 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 large projects is simply much faster than competing solutions for most common commercial configurations and operations… especially ones that include remote teams, large binary assets, and NFS file systems.

Is there a rule of thumb for what size of repos benefits from BK? (And I suppose size could either be the size of a current commit or the total size of the repo.)

Are there any companies like github or bitbucket that support BitKeeper repos?

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

#79

Post by atombender »

peonicles wrote: post #69
adharmad wrote: post #63

Earlier quoted context omitted.

Thank you for contributing to the development and evangalizing of DVCS, directly (BK) and indirectly (the ideas and inspiration for git, hg).

It's probably fair to say the DVCS accelerated the growth of the entire software industry. Was BitKeeper the first version control system to "think distributed" ?

Sun's TeamWare [1] was probably the first real distributed version control system. It worked on top of SCCS. Larry McBoy, BitKeeper's creator, was involved in its development. I believe BitKeeper also uses parts of SCCS internally.

[1] https://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare

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

#80

Post by nickpsecurity »

nostrademons wrote: post #71
luckydude wrote: post #58

Earlier quoted context omitted.

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 :) As to why that license, I think it was because LLVM or clang or both had recently…

(Apache2 has a number of explicit clauses that make it preferable for open-sourcing commercial software. For example, it automatically grants a patent license for any patents used by the software, but then terminates that license if a licensee sues over that software only [as opposed to React's original patent clause, which could be construed as terminating the license if you sue Facebook at all and got them into a l…

Great explanation. Allowing use of, but limiting effect on, patents is critical to get more OSS out of big, patent-loving companies. Let's them know they still have their power and profit while doing something altruistic. Or that helps them in the long-run (free labor) while accidentally being altruistic. Works for me either way. ;)
Post reply on HN