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

51–60 of 309 posts

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

#51

Post by jordigh »

isxek wrote: post #36
luckydude wrote: post #32

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

As someone who's also read about how Git and Mercurial started (and how Bitkeeper is involved in it), I'm interested in seeing how it will play out. I hope it does work out for you and your team. Thanks for getting it out there. I'm also interested how open-sourcing BK will improve the other systems, too.

> I'm also interested how open-sourcing BK will improve the other systems, too.

#mercurial in Freenode right now is monitoring this thread, very relevant to our interests.

Someone at Facebook in #mercurial right now is trying it on some Facebook repo, to compare performance.

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

#52

Post by luckydude »

hansihe wrote: post #42
luckydude wrote: post #15

Earlier quoted context omitted.

It tracks renames, it's not like git. Every file has an internal identifier, that's the actual file id, the name is a versioned attribute of the file.

How does it detect renamed files in the filesystem? Thank you for open sourcing by the way, I can definitely see how some features (binary file handling, submodule handling) could be useful for large-scale projects like games.

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/random and they are guaranteed to be unique if your DNS config is correct (we don't create duplicate keys, look for the uniq db in the code).

The way we version the entire tree is simple, it's logically (implemented differently for performance):

     
     
    ...
where each rootkey uniquely identifies a file and each delta key identifies the tip as of that commit.

Not sure if that is clear enough or not, ask away if not.

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

#53

Post by pklausler »

qwertyuiop924 wrote: post #44
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…

I though SCCS had the same problems as RCS. What did it do differently?

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 clone UPDATE, were kind of like SCCS. Each line (actually card image!) was tagged with the ids of the mods that created and (if no longer active) deleted it.

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

#54

Post by appleflaxen »

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…

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

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

#55

Post by wscott »

jordigh wrote: post #51
isxek wrote: post #36

Earlier quoted context omitted.

As someone who's also read about how Git and Mercurial started (and how Bitkeeper is involved in it), I'm interested in seeing how it will play out. I hope it does work out for you and your team. Thanks for getting it out there. I'm also interested how open-sourcing BK will improve the other systems, too.

> I'm also interested how open-sourcing BK will improve the other systems, too. #mercurial in Freenode right now is monitoring this thread, very relevant to our interests. Someone at Facebook in #mercurial right now is trying it on some Facebook repo, to compare performance.

If they are interested we would be happy to help them tune performance.

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

#56

Post by to3m »

AstralStorm wrote: post #39
stonemetal wrote: post #34

Earlier quoted context omitted.

It claims to be able to handle binary files well which would be a big deal to game development. They have mostly passed on git and mercurial since they can't handle game assets.

They actually can. There is just no good way to version many file formats. Git-pack would have to be extended with support for feels compression of so many formats it is not even funny. And leaving those files outside version control is as easy as always. The about only difference is that git prefers the whole history and you cannot yet set per submodule shallow clone policy. It wouldn't even be too hard to add that.

I don't agree about leaving files outside version control - this always ends in tears.

Regarding versioning, you can always version any file by storing every revision and compressing them as best you can. I believe this is what Perforce does. Repo size can of course become an issue, and git doesn't do a great job with that, since it stores everything, and stores it locally. Perforce can at least discard old revisions and lets you select history depth on a per-file or file type basis.

The more serious problem with git in my view is that there's no good automated merging tools for many types of files, nor are any likely to arise. And more importantly, most people working on your average game aren't interested in forming in-depth mental models of how their tools work, and certainly don't want to have to pick up the pieces when they go wrong. So for most files, you need an exclusive lock (check in/check out, lock/unlock, etc.) model, or similar. That works quite well. But for obvious reasons, git just doesn't support this model at all, and I believe Mercurial is the same - and no amount of transparent/magic large file storage backends or whatever are going to fix that.

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

#57

Post by durin42 »

stonemetal wrote: post #34
luckydude wrote: post #11

Earlier quoted context omitted.

Probably the single biggest reason, aside from it's easier to use than git's CLI, is that it has sub-modules that work exactly like files do in a repository. No extra options, just clone/pull/push/commit/etc. Full on distributed workflow. BitKeeper itself is a collection of repositories. Download an install image, install, and clone it: $ bk clone http://bkbits.net/u/bk/bugfix $ cd bugfix $ bk here PRODUCT default $…

It claims to be able to handle binary files well which would be a big deal to game development. They have mostly passed on git and mercurial since they can't handle game assets.

Some game shops have had good luck with Mercurial's largefiles extension, for what it's worth.

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

#58

Post by luckydude »

appleflaxen wrote: post #54
luckydude wrote: post #32

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

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 picked that and all the lawyers at all the big companies liked that one. We don't particularly care, if everyone yells that it should have been GPL we'll fork it and relicense it under the GPL. Our thought was that Apache is well respect and even more liberal than the GPL but we can be convinced otherwise.

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

#59

Post by isxek »

jordigh wrote: post #51
isxek wrote: post #36

Earlier quoted context omitted.

As someone who's also read about how Git and Mercurial started (and how Bitkeeper is involved in it), I'm interested in seeing how it will play out. I hope it does work out for you and your team. Thanks for getting it out there. I'm also interested how open-sourcing BK will improve the other systems, too.

> I'm also interested how open-sourcing BK will improve the other systems, too. #mercurial in Freenode right now is monitoring this thread, very relevant to our interests. Someone at Facebook in #mercurial right now is trying it on some Facebook repo, to compare performance.

Ha! I'll be checking that out in Freenode now. (Wonder what mpm would say after all this time...)

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

#60

Post by SwellJoe »

bcantrill wrote: post #37

The grand irony is that Larry was one of the earliest advocates of open sourcing the operating system at Sun[1] -- and believed that by the time Sun finally collectively figured it out and made it happen (in 2005), it was a decade or more too late.[2] So on the one hand, you can view the story of BitKeeper with respect to open source as almost Greek in its tragic scope: every reason that Larry outlined for "sourcewar…

I've read that "sourceware" article before, in the distant past when it was still a roughly accurate picture of the market (maybe 1995 or 1996). It's weird to read it again now, in a world that is so remarkably changed. Linux, the scrappy little upstart with a million or so users at the time of the paper, is now the most popular OS (or at least kernel) on the planet, powering billions of phones and servers. NT was viewed as the unfortunate but inevitable future of server operating systems.

I remember looking at IT jobs back then, and seeing a business world covered in Windows NT machines; I even got my MCSE (alongside some UNIX certifications that I was more excited about), because of it. Looking at jobs now, the difference is remarkable, to say the least. Nearly every core technology a system administrator needs to know is Open Source and almost certainly running on Linux.

And, the funny thing is that the general prescription (make a great Open Source UNIX) is exactly what it took to save UNIX. It just didn't involve any of the big UNIX vendors in a significant way (the ones spending a gazillion dollars on UNIX development at the time). Linux got better faster than Sun got smarter, and ate everybody's lunch, including Microsoft. Innovator's Dilemma strikes again.

Apple is an interesting blip on the UNIX history radar, too...though, they're likely to lose to the same market forces in the end, as phones become commodities. I'm a bit concerned that it's going to be Android, however, that wins the mobile world since Android is nowhere near the ideal OS from an Open Source and ethical perspective; but, I guess they got the bits right that Larry was suggesting needed to be right.

Anyway, it was a weird flashback to read that article. Things change, and on a scale that seems slow, until you look back on it, and see it's "only" been a couple of decades. In the grand scheme of things, and compared to the motion of technology prior to the 1900, that's a blink of an eye.

Post reply on HN