luckydude

It was good run, not many software companies get an 18 year run. I'm fine with it, would have liked to do more for my people.

Though, when we were shutting things down and I was bumming that I had not gotten retirement money for all of my people, one of them said something like "Dude, are you kidding me? My best friend barely knows his kids, he is out the door by 7am to fight Houston traffic and not home until close to 7pm. My commute is from my bedroom to my office down the hall. I've got to help my wife with the kids, I see the kids all day every day, my life is infinitely better than my friend's life and you gave that to me. You're fine."

I'm a wimp, I teared up a bit, that was the nicest thing he ever said to me. It's not just about money.

When we were still in business, each new SCM that came out, we'd hold our breath until we looked at it and said "No weave!"

For those who don't know, the SCCS weave is how your data is stored. Most people are used to something like RCS which is patch based. For the RCS trunk, the head is stored as plain text, the previous delta is a reverse patch against the head, lather, rinse, repeat. Branches are forward deltas, so if you want to get something on a branch, you start with the head, apply reverse deltas until you get to the branch point and then forward deltas until you get to the branch tip. Ask Dave Miller how much he loved working on a branch of gcc, spoiler, he hated it. With good reason.

SCCS has a weave that is not aware of branches at all, it only knows about deltas. So you can get 1.1 in exactly the same amount of time as it takes to get head, it is one read through all the data. bk annotate (git blame) is astonishingly fast.

And merges are by reference, no data is copied across a merge. Try that in a patch based system. How many of you have been burned because you merged in a branch full of code that someone else wrote, and on the trunk all the new data from the branch looks like you wrote it, so you get blamed when there is a bug in that code? That's because your brain dead system copied code from the branch to the trunk (Git does this as well, that's what the repack code is trying to "fix", it is deduping the copies).

Weaves are the schnizzle, any SCM system that doesn't use them today is so 1980.

Personally, I would love a gcc --little dialect complete with a String type (and others) that is garbage collected and auto resized just like tcl/Little. With all the other Little goodness in there. Man, that would make C super pleasant. And it wouldn't be a new syntax like Go/Rust/whatever.

Unfortunately, even now, it seems that there is a lot catching up to BK still to be done. To be fair, we had kernel level programmers working on it, we don't think anyone will pick up our code, you pretty much have to be a top 1-2% programmer to work on it, it's all in very disciplined C, people don't seem to like that any more.

So far as I know, BK is the only system that gets files right, we have a graph per file, everyone else has a single graph per repository. The problem with that is the repository GCA may be miles away from the file GCA; BK gets that 100% right, other systems guess at the GCA. Graph per file means each file has a unique identifier, like an inode in the kernel. So create/delete/renames are actually recorded instead of being guessed at. SCM systems shouldn't guess in my opinion (actually in anyone with a clue's opinion, would you like it if your bank guessed about your balance? Of course not, so why is guessing OK in an SCM? It's not). Graph per file means that bk blame is instant no matter how much history you have.

BK is the only system that even attempts to get sub-modules (we call them components) right. Where by "right" I mean you can have a partially populated collection and you get identical semantics from the same commands whether it is a mono-repo or a collection of repos. Nobody else has anything close, Git sub-modules turn Gits workflow into CVS workflow (no sideways pulls).

I tried my best to show what we did in BK at that conference, I have no idea if they will swipe any of it. It's not like BK is perfect, it didn't do everything, no named branches, a clone is a branch, which is a model that absolutely will not scale to what people are doing today (we can argue whether TB repos should exist, but they do).

But for the problems BK did solve, it tended to solve them very well. Hell, just our regression tests are a treasure trove of things that can go wrong in the wild and we open sourced both the tests and the test harness.

Been open source for years

I thought that was clever given that tcl's reference counter was signed and it only uses positive values. So we made it unsigned and got the bit for free.

On the other hand, we didn't make enough for everyone to retire if they wanted to. We had a github like offering and it's pretty clear that we should have put a bunch of money into that and open sourced BitKeeper.

All I can say is it is incredibly hard to make that choice when you have something that is paying the bills. I tried to get Sun to do it with the BSD based SunOS and they wouldn't. And even though I had that vision for Sun, when it was my livelihood, I couldn't see the path to doing so.

Shoulda, coulda, woulda, my biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it's a crappy design. It does what he wants, but what he wants is not what the world should want.

It says a lot that we have a bk fast-export and we can incrementally run that and get idempotent results. As in go from BK to Git on an ongoing basis, have two people do it in parallel and they both get bit for bit identical results. If you try and go the other way, Git -> BK, if you do it in parallel you get different results because Git doesn't store enough information, so BK has to make up the missing bits.

Git has no file create|delete|rename history, it just guesses. That's my biggest regret, I wish Linus had copied that part.

http://mcvoy.com/lm/L/tcl/tests/langbench/

some results in the README. Perl holds up well. These are probably 10 years old though.

while (buf = <>)

did. So I didn't want to invent a new syntax, there is way too much of that going on, I like C, I like perl, pull the useful stuff from each and move on.

I freely admit it's not how everyone would do it.

undef is both a function and a (non) value. It is the main reason Little never got pushed back into tcl, the tcl crowd hates the idea that there can be a value for a variable that is undefined. I found that very useful, for example, undef is the error return from any function. Just made sense to me, didn't make sense to the Tcl people.

I'm surprised to see it getting some attention but happily so. Little is what I'd like C to evolve towards, there is a lot of useful (to me) stuff in the language.

I'll wander through the comments and reply where I can.

Here's a snippet of an email I sent him in this morning:

    Can you see how your attitude, if shared by the leaders
    at Facebook, is exactly why Facebook should get regulated?
    It's a my way or the highway, take no prisoners approach,
    and yeah, that will bring regulation.

    If your attitude was more like "yeah, I get it, it's a
    little creepy, we're trying to figure out a way to have a
    business model that works and isn't creepy" then perhaps
    you'd get to regulate yourself.

    The problem is that the lawmakers are clueless, you may
    well get some stupid draconian regulation that you really
    don't want.  If that happens, you are going to look back at
    these emails and go "welp, we blew it, this is our fault".

And I think, might be wrong, but I think github was first.

It's sad, because there are other useful work flows, but GitHub is SCM at this point. I agree with what someone said elsewhere, they could swap out git for bitkeeper and nobody would care (well the people that are still butthurt over the licensing would whine but it's apache v2 now, that should be good enough).

I engage because I want to help. BitKeeper is mostly dead, I've offered to go to facebook and transfer as much as I can to their SCM.

Every day humans make me again realize that I love my dogs, and respect my dogs, more than humans. There are exceptions but they are few and far between.

We built a GUI tool that lets you look at a versioned file, it shows you the graph in the top pane and either diffs between two versions or the contents of a particular version in the bottom pane.

It's the goto tool for figuring out stuff. It is not just a GUI version of "git blame". When you use it you can see the history of each line by hovering over that line, you get a popup that shows the checkin comments for that line. And it is fast, as in below human reaction time, so you use that feature.

And you can double click on any line and boom, you are looking at the changeset that introduced that line.

I'm tired so I'm probably not doing a good job explaining this, but we supported commercial customers for a couple of decades and we had just incredible response time to each issue and I credit this work flow for that. Someone would call and say I have this assert and one of would get into the gui, start looking and we would know the cause of the problem in seconds or single digit minutes and I don't me 5-10 minutes, I mean 1-2 minutes.

Maybe I'm clueless and there is a way to do this in git but I haven't found it. When I have to work with git repos I fast-export them into BK just so I can have a more sane way to look at the history. It's not great history but it's better than Git.

Edit: I didn't explain what that gui did on the ChangeSet file. So that's what gitk (gittk?) is, it shows you the repo graph. You can click on a node and see the commit, you can left click and right click and see the diffs between those changesets.

So far as I know, BK is the only system that puts the metadata in the same system as the user data.

If you want to live in a world where two people can be wacking the repo at the same time with undefined results, be my guest, you seem like that sort of person. We are not. We like atomic commits.

As for BK being expensive compared to Git, you are so right. 10 years ago. These days we do quite well and we do it correctly.

I dunno why you have a hardon to smear BK, but bring it dude, I'm happy to make you look foolish.

I'm not a fan of using a DB to store versions. It's just not the right tool. Before we open sourced, we jealously guarded "the weave" which is how the history data is stored. The weave gives us so much, bk blame is instant, bk grep is instant, there is a "bk grep -R" that will look in all versions of a file that is instant, or you can do "bk grep -R<revs>" and look in just those revs, all instant.

The weave is compact, fast, merges better, it's just a better storage format than a DB. Here's an example. In most version control systems, lets say there is a 100 line file. I clone that repo and I modify the first 51 lines of that file. You clone the same thing I cloned, and you modify the bottom 50 lines of that file. So we have 99 unique lines and 1 line that we both modified. Now Joe Merge clones my repo and merges your repo. He's the guy that closed the DAG. He had to manually merge the one line that we both changed so when you do $SCM blame the correct answer is the top 50 lines are me, the bottom 49 lines are you, and the manually merged line is you, right?

That's what happens in BK. It's not what happens pretty much anywhere else. Either the entire top chunk or the entire bottom chunk will look like it was done by Joe. Why? Because everyone else passes data by value, BK (the weave) passes data by reference. Everyone else copies the data across the merge point. BK does not, the only new data that will be in the merge node is the one line that joe had to merge by hand.

This can have some space savings implications, which can be a big deal for big files, but in my opinion the far bigger implication is blame. Joe merged in your stuff and now your stuff looks like he wrote it. Someone is tracking down a bug and they should be talking to you but they are talking to Joe.

I should write up a blog post about it, it's pretty complicated to understand because to get it, you need to understand SCCS's interleaved delta format. If you understand that format, then imagine that you put a line number in front of each data line in the weave. Check out the GCA, local, and remote versions of the file with those line numbers prefixed. Now run a 3 way merge on that.

All the complexity in smerge.c comes from dealing with the cases where that doesn't work, but man, it works great 99% of the time.

You can, and will, argue they are morons. That's an excellent way to deal with a poorly designed system.

But lots of times you want to look at the file view, find the line of code that looks like the problem, and then zoom out to the changeset. BK makes that trivial, Git makes that miserable to impossible.

[1] Actually there was a little known system, Aide-de-camp, that one of my people told me about that had changesets so I didn't invent it, but I reinvented it. And made the world aware of the concept. Back when you could search Usenet via dejanews you could search for "changeset" and date limit it to before me talking about it. There were maybe 5 hits. A few years after BK came along there were 100's of thousands of hits. So I wasn't first but I am definitely the reason that you know what a changeset is.

http://www.mcvoy.com/lm/photos/2007/05/276.html

ZFS guys (Brian, Jeff and Bill) at the same party (I thought I had one with Linus and them, they were all at the same table talking file systems):

http://www.mcvoy.com/lm/photos/2007/05/257.html

Funny story, I invited Linus to the pig roast and he didn't RSVP so there wasn't anywhere for him to sleep. I ended up sticking him and his daughter in a VW popup van :)

You can kindly wander off now, random internet dude. Especially since the guy who wrote Git agrees that it is lossy, so take your FUZZY and go home.