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

271–280 of 309 posts

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

#271

Post by mwcampbell »

ryao wrote: post #229
drostie wrote: post #110

Earlier quoted context omitted.

Because the diagrams for hg are very simple, there is a really simple way to do branching that obviously works and commits a relatively forgivable sin: just `cp -a` the folder. Now, I know that that's in essence an admission of defeat! I'm not pretending that it's anything less than that. However, this is also the easiest explanation of, and model for, branching that anyone has ever created. The explanation of branch…

> I'm really surprised that software developers aren't more the sort to really say "why am I doing this?" and to prefer systems which make it easier to answer those questions with pretty pictures. The network effect should explain it. That said, using pictures to answer questions is fairly sadistic when those asking them are blind. I know a blind developer and I never use pictures when talking to him in IRC.

How did Git's network effect get started in the first place?

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

#272

Post by wyoung2 »

Frondo wrote: post #264
wyoung2 wrote: post #244

Earlier quoted context omitted.

> Fossil's wiki and ticketing system are awful Care to be more specific? I'll grant that Fossil's wiki is not a competitor to MediaWiki, but that doesn't make it "awful." It just makes it less featureful. So, what feature do you need in a wiki that Fossil's wiki does not provide? As for the ticketing system, again, it isn't going to replace the big boys out of the box, but it also doesn't have to match them feature-f…

Oh, I used Fossil as my only VCS for 3 or 4 years. On my biggest projects, I had a heavily tweaked ticketing system and probably a hundred wiki pages. My experience with Fossil wasn't a "well the defaults suck, next thing" kind of situation for me, I was pretty invested in it. I also ditched it all 3 or 4 years ago, so my memory's not great, but what got me about the ticketing was that, for whatever reason, I could n…

> I could not sit any non-technical user in front of it and have it make sense to them

So name a bug tracker with equivalent or greater flexibility to Fossil's that non-technical users do understand.

I've only used one bug tracker that's simpler than Fossil's, and that's because it had far fewer user-facing features.

Every other bug tracker I've had to use requires some training once you get past the "submit ticket" form. And a few required training even to successfully fill that out!

> Fossil's lack of any built-in emailing was also lousy.

Email is hard. Seriously hard. RFCs 821 and 822 are only the tip of an enormous iceberg. If Fossil only did the basics, it would fail for a whole lot of real-world use-cases, and it'll only get worse as email servers get tightened down more and more, to combat spam, email fraud, domain hijacking, etc.

I, too, would like Fossil to mail out commit tickets and such, but I'm not sure I want the build time for the binary and the binary size to double just because of all the protocol handlers it would need to do this properly. Keep in mind also that Fossil generally doesn't link out to third-party libraries. There are exceptions, but then, I'm not aware of a widely-available[1] full-stack SMTP library, so it would probably have to reimplement all of it internally.

Now, if you want to talk about adding a simple gateway that would allow it to interface with an external MTA, that would be different. I suspect the only thing wanting there is for someone to get around to writing the code. I don't want it bad enough to do it myself.

> "it's supposed to work that way" instead of "hey, maybe you, the user, are onto something".)

If you propose something that goes against the philosophy of Fossil, then of course the idea will be rejected. We keep seeing git users ask about various sorts of history rewriting features for example. Not gonna happen. No sense having a philosophy if a user request can change it.

If you're talking about a Fossil behavior that isn't tied to its philosophy, but it just works the way it does for some reason, logic and persuasion are a lot less effective than working code. The Fossil core developers accept patches.

----------

[1] I mean something you can expect to be in all the major package repositories, and in binary form for Windows.

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

#273

Post by sinxoveretothex »

ajb wrote: post #200
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" ?

There was a paper published on a DVCS using UUCP (!) in 1980: "A distributed version control system for wide area networks " B O Donovan, http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...

The date of publication on Xplore is September 1990 though?

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

#274

Post by neandrake »

glandium wrote: post #188
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.

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.

The only way I'm familiar with instructing mercurial to do this is with

    hg addremove -s
Is there another way to indicate a rename?

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

#275

Post by luckydude »

bch wrote: post #265
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…

> realize that Tichy pulled the wool over our eyes. ref: https://en.wikipedia.org/wiki/Revision_Control_System , https://en.wikipedia.org/wiki/Walter_F._Tichy

Yeah, that. I think he got a PhD for RCS and what he should have gotten is shown the door. RCS sucks, SCCS is far, far better.

Just as an example, RCS could have been faster than SCCS if they had stored at the top of the file the offset to where the tip revision starts. You read the first block, then seek past all the stuff you don't need, start reading where the tip is.

But RCS doesn't do that, it reads all the data until it gets to the tip. Which means it is reading as much data as SCCS but only has sorta good performance for the tip. SCCS is more compat and is as fast or faster for any rev.

And BK blows them both away, we lz4 compress everything which means we do less I/O.

RCS sucked but had good marketing. We're here to say that SCCS was a better design.

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

#276

Post by luckydude »

nullnix wrote: post #259
luckydude wrote: post #231

Earlier quoted context omitted.

We support the uuencode horror for compat (and for smaller binaries that don't change) but the answer for binaries is BAM, there is no data in the weave for BAM files. I don't agree that the weave is horrible, it's fantastic for text. Try git blame on a file in a repo with a lot of history then try the same thing in BK. Orders and orders of magnitude faster. And go understand smerge.c and the weave lightbulb will com…

Yeah, that's the problem; it's optimizing for the wrong thing. It speeds up blame at the expense of absolutely every other operation you ever need to carry out; the only thing which avoids reading (or, for checkins, writing) the whole file is a simple log. Blame is a relatively rare operation: its needs should not dominate the representation. The fact that the largest file you mention is frankly tiny shows why your p…

Give me a file that was slow and lets see how it is in BitKeeper. I bet you'll be impressed.

50K lines is not even 3x bigger than the file I mentioned. Which we check out in 20 milliseconds.

As for optimizing blame, you are missing the point, it's not blame, it's merge, it's copy by reference rather than copy by value.

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

#277

Post by luckydude »

SwellJoe wrote: post #261
Annatar wrote: post #220

Earlier quoted context omitted.

> Great is a relative term. But, can you name an OS, especially a UNIX, that is better in the general case? By "general case", I mean, good for just about anything, even if there's something better for some niche or role. Also, take into account the world we live in: More computing happens on servers and phones than on desktops and laptops; and judge the OS based on how it's doing in those roles. Okay then, SmartOS.…

I'm struck by how much this sounds like a Linux fan ranting back in 1995, when Windows and "real" UNIX was king. The underdog rants were rampant back then (I'm sure I penned a few of them myself). I think the assumption you're making is that people choose Linux out of ignorance (and, I think the ignorance goes both ways; folks using Solaris have been so accustomed to Zones, ZFS, and dtrace being the unique characteri…

I predate the Solaris stuff, I'm not a fan. I liked SunOS which was a bugfixed and enhanced BSD. When I wrote the sourceos paper I was talking about SunOS. (I lied, I overlapped with Solaris but I try and block that out)

All that said, Sun had an ethos of caring. In the early days of bitmover amy had some quote about the sun man pages versus the linux man pages, if someone can find that, it's awesome. We keep a sun machine in our cluster just so we can go read sane man pages about sed or ed or awk or whatever. Linux man pages suck.

Sun got shoved into having to care about System V and it sucked. I hated it and left, so did a bunch of other people. But Sun carried on and the ethos of caring carried on and Bryan and crew were a big part of that. My _guess_ is that Solaris and its follow ons are actually pleasant. I'll be pissed if I install it and it doesn't have all the GNU goodness. If that's the case then you are right, they don't get it.

What I expect to see is goodness plus careful curating. That's the Sun way.

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

#278

Post by luckydude »

jordigh wrote: post #48
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...

Just for the record this thread is where I learned that. And yup, it sorta fits. For better or worse.

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

#279

Post by luckydude »

ryao wrote: post #184
tw04 wrote: post #90

Earlier quoted context omitted.

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.

Some history. I was at Sun and Bob Hagmann was teaching at Stanford and got me to be a TA there. He retired and Stanford asked me if I would teach CS240B so I did. Jeff Bonwick was student and I recognized his ability and recruited him to Sun. He said "I have no experience programming in C" and I said "You are smart. I can teach you C, I can't teach you smart".

I also told him that he'd go way farther at Sun than I did and I was right, I think he made DE, I didn't. He played the game better. Smart guy. Him, Bryan, Bill Moore, those guys were the new Sun in my mind.

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

#280

Post by luckydude »

ryao wrote: post #226
debaserab2 wrote: post #183

Earlier quoted context omitted.

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

I wrote enough patches to ZFSOnLinux that I have the distinction of number 2 by commit count. It was a hobby for me at first and quite frankly, I never expected it to make a difference for more than a few hundred people. Now ZoL is on millions of systems through Ubuntu in part because of my work and there are far more places using it than I can count. Open sourcing those patches rather than keeping them to myself mad…

I still think you need to look at it from the point of view of an employer. Like me. I'm weird, I really care about my people, our company is more like a cooperative than anything else.

I grew this to a place where I could pay salaries. Doing so was super super hard. I had a lot of scary nights where I thought I couldn't make payroll. Just building up to a place where the next payroll was OK was a big deal for us.

So open source it? When you finally got to the point where you can pay people without worrying all night?

I get that you see that open source is the answer, and it is for some stuff. For me, jumping on that years ago was asking too much.

Post reply on HN