Live data from Hacker News

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

bitkeeper.org

181–190 of 309 posts

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

#181
post #161

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…

This distinction between branches and bookmarks looks like one of the things missing the most from git. Grab a random branch from some place and try to guess whether the committer intends to rewrite it in the future or not: good luck.

For the rest: https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...

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

#182
post #177
post #161

Earlier quoted context omitted.

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.

So what about all this contradicts "branching in hg is pretty much broken"?

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

#183
post #170

Earlier quoted context omitted.

Except that we've been around for 18 years and made payroll without fail that entire time. Supported a team of 10-15 people every year. That's something, many many companies in the valley, including many that open sourced everything, have not done as well. You may have done more by open sourcing whatever it is that you have done; if so congrats.

My remark was intended to cite how much farther bit keeper could have gone had it been open source from the start rather than belittle what bit keeper accomplished. At work, many of my newer colleagues have backgrounds in closed source software development. We are developing software that has no exact analog to existing software, and we hope that it will have a big impact. If it becomes as important as we think it co…

Except you're not Linus and you probably don't have a cult like following for any work you produce.

Linus brought DVCS to the masses, but to pretend there wasn't more at play than simply open sourcing a project and hoping it all works out is complete rubbish. People have families to feed. Closed source is not inherently evil.

It takes a unique situation to produce something like git that's product is beyond the sum of the project itself.

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

#184
post #90

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…

> ZFS may have never seen the light of day if Solaris were open sourced in 1995.

It depends on how that would have affected Jeff Bonwick. If it kept him from deciding that Sun ought to develop a new filesystem, promising Matthew Ahrens a job writing one out of college and working together with Matt on it, ZFS would never have existed.

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

#185
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/

From what I read, he connected to a bit keeper repository via telnet on port 5000, executed the help command and then used that information to write an incomplete client. That does not sound like reverse engineering to me.

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

#186
post #177

Earlier quoted context omitted.

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

So what about all this contradicts "branching in hg is pretty much broken"?

Your original comment linked broken branches with the fact that they can't be deleted. That's only true if you intended to talk about Mercurial named branches which aren't broken, they just aren't what you want them to be.

Bookmarks (today, and for several years) work just fine. So "branching" in the general sense isn't broken even though the combined feature set is a bit haphazard.

That bitbucket doesn't work well with bookmarks is a sign of how little Atlassian cares about hg, rather than an hg issue.

If you're arguing that the hosting options for hg are limited and fall far below the git options, then I'm not going to disagree.

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

#187
post #179

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…

> 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?

he explained the move in another comment https://news.ycombinator.com/item?id=11668492

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

#188

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.

What's not clear from your replies is whether it tracks renames like mercurial, by having users run a manual command to ensure the VCS know about the rename. Except if bk has a file system monitor, I'll assume that's what it does. Unfortunately, data on a few Mercurial repositories I looked at (Mozilla's and Mercurial's) shows that people don't mark all file renames.

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

#189

Earlier quoted context omitted.

My $0.02 canadian; Build something that kicks Gitlab and Github's ass. What an opportunity. Support both BK and GIT repos. Provide a distributed workflow that enterprises will love. Enterprises are obviously where the remaining dollars are. There are billions of dollars of inefficiencies in that sector. Many of these enterprises do NOT want to host their code on Github and are buying Gitlab. Be better than Gitlab.

^^ this. PLEASE. :-( Bitbucket has been rotting since Atlassian bought them, and now there's really no "killer app" for Mercurial hosting. There are Mercurial hosting services out there, but nothing anywhere close to Github/Gitlab.

doesn't github support mercurial?

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

#190
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…

If I remeber the history correctly, per-file commit messages were actually a feature that was quickly hacked in to get MySQL on board. It did not have that before those MySQL talks and I don't think it was very popular after.

Performance indeed killed bzr. Git was good enough and much faster, so people just got used to its weirdness.

Post reply on HN