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

171–180 of 309 posts

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

#171

Post by melloc »

luckydude wrote: post #6
okket wrote: post #3

There is an official mirror on GitHub: https://github.com/bitkeeper-scm/bitkeeper

It's a read only mirror, the read/write mirror is on bkbits.net. But we'll maintain the mirror (or you can, bk has fast-export which creates a perfect mirror in git).

Is there a way to do the reverse, and convert a Git repository into a BitKeeper repository? I found the fast-export manual page:

https://www.bitkeeper.org/man/fast-export.html

But it doesn't look like there's any fast-import. Do you have some recommended way if I wanted to convert an existing repository to try BitKeeper out?

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

#172

Post by bcantrill »

luckydude wrote: post #123
bcantrill wrote: post #101

Earlier quoted context omitted.

That is my understanding, yes -- but the NSE and (McVoy-authored) NSElite chapters of the saga pre-date me at Sun. Before my "Fork Yeah!" talk[1][2], from which this is drawn, I confirmed this the best I could, but it was all based only on recollections of the engineers who were there (including Larry). I haven't found anything written down about (for example) NSElite, though I would love to get Larry on the record t…

The NSE was Suns attempt at a grand SCM system and it was miserably slow (single threaded fuse like COW file system implemented in user space). I did performance work back then, sort of a jack of all trades (filesystem, vm system, networking, you name it) so Sun asked me to look at it. I did and recoiled in horror, it wasn't well thought out for performance. My buddies in the kernel group were actually starting to qu…

Wow, jackpot -- thank you! That 2000th resync is a who's who of Sun's old guard; many great technologies have been invented and many terrific companies built by the folks on that list! I would love to see the nselite man pages that the README refers to (i.e., resync(1) and resolve(1)); do you happen to still have those?

Also, even if privately... you need to name that VP. ;)

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

#173

Post by alexeiz »

drostie wrote: post #109
dsp1234 wrote: post #98

Earlier quoted context omitted.

"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." Are they talking about hg or git here. Because that flow in git is: git branch git checkout git commit git push The only thing that git adds to that workflow is that creating a new branch doesn't immediately move you ont…

Ahahahahahaha. You think that works! No. That fails with the following semi-helpful error message: remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match rem…

Why is it that some people get Git naturally and some experience a world of frustration trying to use it? I think the kind of problems you describe usually come up if you approach Git with a mindset formed by another SCM. They are typical for people who are proficient with, say, SVN and who try to use Git thinking that Git must work something like SVN. (I'm using SVN as just an example here; it could be any other SCM, but I most frequently see people coming from SVN to really struggle with Git.) Well, Git is nothing like SVN and you'll always be missing something if you try to understand Git through SVN concepts. It's best to forget what you used before and learn Git from a clean slate. Maybe I was just really lucky to never having to learn SVN (or CSV or ClearCase), so Git concepts and workflows were clear and almost effortless to understand and use. Or maybe it's like the concept of pointers: some people get it right away and others never get it.

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

#174

Post by happosai »

luckydude wrote: post #141
ashitlerferad wrote: post #139

Too late :)

You and a lot of other people say that. Sure, if we want to take over from Git, it's late. But Git has left us with an opening, the only way Git works for the masses is Github, Git itself is too complicated and people "lose" their data (they don't but Git makes it appear like they did). I think people will play with BK and find out that it can work for everyone without something like Github (we still need it but it's…

The "too late" comments are depressing since they totally lack insight (who hasn't noticed the dominations of gits?). Yet also here in HN specifically you would expect people to cheer for pivoting into something new. Thanks for open sourcing BK.

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

#175

Post by Frondo »

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…

Here's my dream DVCS: easily self-hostable like Fossil, but with good wiki and ticketing system. (Fossil's wiki and ticketing system are awful, but what really sunk it for me was its unexpected behavior for basic commands like "fossil rm".)

I'm just not super-fond of relying on Bitbucket, reliable though they've been, for hosting my stuff.

But a package I could toss on my own VPS? I'd toss some money at that. Wouldn't even need it to be open-source, but I'm no zealot.

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

#176

Post by Mathiasdm »

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.

Mercurial has had 'largefiles' since Mercurial 2.0, 5 years ago.

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

#177

Post by jurip »

timv wrote: post #161
anarazel wrote: post #104

Earlier quoted context omitted.

Maybe I'm a too long time user of git, but I really fail to see why git as of the last 5 years is any harder to explain than hg. Personally I think the branching in hg is pretty much broken; alone the fact that it's pretty much impossible to get rid of branches is horrible.

I think that the hate that gets lumped on mercurial's branches, though understandable, is a bit unfair Disclaimer, it's been years since I used hg as my primary DVCS. So some of my thoughts here might be out of date, or have a misrecollection. > branching in hg is pretty much broken* It really isn't. It's absolutely not suited for the task that many people want to use it for, but it's totally fitting with the intende…

> So even today, the "branch" concept in hg is only useful for a small number of cases, and the "bookmarks" concept is what most people want, but they're separate things with names that don't align with expectations.

And it doesn't help that the primary hosted repository system is Bitbucket and Bitbucket didn't support pull requests from bookmarks last time I checked.

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

#178

Post by skew4 »

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…

10 or even 20% performance is not a feature. But when tools or features get a few times faster or more then their usage model changes - which means they become different features.

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

#179

Post by ryao »

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…

> in both cases, the companies acted in self interest. Neither had the guts to walk away from their existing revenue stream.

Why does bitmover have the guts now?

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

#180

Post by ryao »

adharmad wrote: post #63
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…

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

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

I concur.

Post reply on HN