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

41–50 of 309 posts

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

#41

Post by luckydude »

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…

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 the wool over our eyes. SCCS is profoundly better.

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

#42

Post by hansihe »

luckydude wrote: post #15
PuercoPop wrote: post #13

Something I'm wondering and the man page doesn't clear, does it track files across renames or does it only track content like git?

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.

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

#43

Post by qwertyuiop924 »

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 actually posted before I saw your comment. I guess I was right. So are you happy to finally have an open source bring-over-modify-merge VCS whose command set makes sense?

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

#44

Post by qwertyuiop924 »

luckydude wrote: post #41
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…

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?

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

#45

Post by devnonymous »

Great news! Better late than never! I hope they (or a client of theirs) create a BK backed service soon. I for one, think we need more than just github and altassian in the market if only to ensure the businesses don't take their users for granted (hint: sourceforge)

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

#46

Post by stephenr »

Amongst all the "too late I loves me some git" type comments, i figure I'd say thankyou and good luck with continued revenue.

I haven't read much about bk so far, so forgive my lazy web question: does/can bk operate over standard ssh as git/hg/svn can, or does it require a dedicated listening server to connect to?

Edit: answering my own question, yes it does support ssh as a transport

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

#47

Post by rbanffy »

luckydude wrote: post #41
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…

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.

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

#48

Post by jordigh »

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…

This is a bit funny because Mercurial is partly named after Larry.

https://groups.google.com/d/msg/mercurial_general/c3_SM3p7S1...

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

#49

Post by [deleted] »

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.

[deleted]

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

#50

Post by luckydude »

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?

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". The time to get the tip is the same as the time to get the first version or any version. The file format looks like

  ^AI 1
  this is the first line in the first version.
  ^AE 1
That's "insert in version 1" data "end of insert for version one".

Now lets say you added another line in version 2:

  ^AI 1
  this is the first line in the first version.
  ^AE 1
  ^AI 2
  this is the line that was added in the second version
  ^AE 2
So how do you get a particular version? You build up the set of versions that are in that version. In version 1, that's just "1", in version 2, that's "1, 2". So if you wanted to get version 1 you sweep through the file and print anything that's in your set. So you print the first line, get to the ^AI 2 and look to see if that's in your set, it isn't, so you skip until you get to the ^AE 2.

So any version is the same time. And that time is fast, the largest file in our source base is slib.c, 18K lines, checks out in 20 milliseconds.

Post reply on HN