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

81–90 of 309 posts

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

#81

Post by TickleSteve »

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…

git is the primary example of how bad Linus Torvalds is at writing UI code.... ;o)

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

#82

Post by 4ad »

luckydude wrote: post #52
hansihe wrote: post #42

Earlier quoted context omitted.

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

What happens when you duplicate a file? Does it track history back to the original parent? Can it help with future merges?

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

#83

Post by luckydude »

atombender wrote: post #79
peonicles wrote: post #69

Earlier quoted context omitted.

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

We did a clean room reimplementation of SCCS and added a pile of extensions.

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

#84

Post by clacke2 »

luckydude wrote: post #50
qwertyuiop924 wrote: post #44

Earlier quoted context omitted.

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

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".…

Aha, so that's where bzr got it from. :-)

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

#85

Post by luckydude »

4ad wrote: post #82
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/…

What happens when you duplicate a file? Does it track history back to the original parent? Can it help with future merges?

You mean copy the file? There is a bk cp command that copies the file and gives it a new rootkey. But from that point on the history of the two files diverge.

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

#86

Post by clacke2 »

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…

GPLv3 is Apache 2 compatible, which GPLv2 isn't. Most other permissive licenses are compatible with any GPL.

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

#87

Post by luckydude »

clacke2 wrote: post #84
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".…

Aha, so that's where bzr got it from. :-)

bzr got more than that from BK, it got one of my favorite things, per-file checkin comments. I liken those to regression tests, when you start out you don't really value them but over time the value builds up. The fact that Git doesn't have them bugs me to no end. BZR was smart enough to copy that feature and that's why MySQL choose bzr when they left BK.

The thing bzr didn't care about, sadly, is performance. An engineer at Intel once said to me, firmly, "Performance is a feature".

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

#88

Post by clacke2 »

jwilk wrote: post #28

"[...] Linus moved to it and most of the developers followed. They stayed in it for three more years before moving to Git because BitKeeper wasn't open source." Um, the "because" part is not quite right.

Glosses over things, but is essentially accurate. Lots of people were not willing to use a proprietary tool, which prompted some reverse-engineering, which caused BK to withdraw their offer.

If all free software activists had accepted the compromise of using the free-as-in-beer BK, git would never have been created.

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

#89

Post by clacke2 »

luckydude wrote: post #87
clacke2 wrote: post #84

Earlier quoted context omitted.

Aha, so that's where bzr got it from. :-)

bzr got more than that from BK, it got one of my favorite things, per-file checkin comments. I liken those to regression tests, when you start out you don't really value them but over time the value builds up. The fact that Git doesn't have them bugs me to no end. BZR was smart enough to copy that feature and that's why MySQL choose bzr when they left BK. The thing bzr didn't care about, sadly, is performance. An eng…

Cool. I've used bzr but never knew about per-file comments.

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

#90

Post by tw04 »

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…

Sun is also no more... and it's not at all clear they would've survived had Solaris been open sourced a decade earlier.

Yes, you're absolutely right that there are a ton of startups built on opensolaris (who have proprietary code they haven't and don't intend to ever give back to the community), and there is smartos/omnios/illumos as well. But none of those projects would have in any way contributed to the health of Sun Microsystems, nor provided the funding to get Solaris to where it is today. ZFS may have never seen the light of day if Solaris were open sourced in 1995.

Post reply on HN