6 ms·

Hind sight is 20-20. The BitKeeper business had a good run, we were around for 18 years. It made enough that I and my business guy are retired off of what we

Hind sight is 20-20. The BitKeeper business had a good run, we were around for 18 years. It made enough that I and my business guy are retired off of what we made. 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.

brundolf 6y ago
I hadn't heard of BitKeeper but it sounds interesting. Have you considered open-sourcing it now for people to look at, even though the business has faded?
- luckydude 6y ago
  http://bitkeeper.org http://bitkeeper.org Been open source for years
- momszack 6y ago
  This makes me feel old. The bitkeeper saga is why GitHub exists. The drama is archived in 2004-5 lkml.
  - brundolf 6y ago
    I was twelve :)
JNRowe 6y ago
Now that all that isn't so raw, I'd love to know how you felt about the other contenders that were floating about at the time. Were any of them doing things you wanted to see in BK? I can't be the only one who'd be interested in your views on the general developments for such important tools of our trade. Have you written about it anywhere? I'll pre-order "Larry walks us from SCCS to the git monoculture".
- luckydude 6y ago
  Actually I was part of an SCM conference put together by Facebook and Google recently. People are starting to think about what happens after Git. 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.
temporallobe 6y ago
I know Git quite well at this point in my career, but it’s still a very baffling and often frustrating SCM tool in my opinion. I find it disconcerting that despite many years with it, I still feel like I don’t totally comprehend what really is happening under the hood. There seems to be a lot of magic. I still have a sense of apprehension every time I do a rebase, and after successful conflict resolution I am surprised that it somehow worked given how messy and convoluted the rebase workflow is. One of the oddest things I more recently learned about Git is that you can’t create empty folders. The workaround is to create an empty file (e.g., a README)! That being said, entire careers are built on this powerful yet odd tool that has somehow become the most popular SCM system in the world.
- scruple 6y ago
  > One of the oddest things I more recently learned about Git is that you can’t create empty folders. The workaround is to create an empty file (e.g., a README)! The convention I've seen is `.keep` and `.gitkeep`.
hyperpallium2 6y ago
I so appreciate you answering questions here! I've experienced how Git's lack of file rename makes it hard to follow changes through directory and file reorganization. This made me reluctant to reorganize, as I learned the problem space. The general, long-term impact may be increased ossification pressure. OTOH linus's content addressable system is absurdly, compellingly simple, and does 90%. It's disproportionately simple. A dilemma! BTW I think many companies get killed that way. Refusing revenue to profit must be pollyanna - except for github. OTOH keeping customers is how great companies get killed, according to Christensen (the innovator's dilemma).

brundolf 6y ago

I hadn't heard of BitKeeper but it sounds interesting. Have you considered open-sourcing it now for people to look at, even though the business has faded?

luckydude 6y ago
http://bitkeeper.org http://bitkeeper.org Been open source for years
momszack 6y ago
This makes me feel old. The bitkeeper saga is why GitHub exists. The drama is archived in 2004-5 lkml.
- brundolf 6y ago
  I was twelve :)

JNRowe 6y ago

Now that all that isn't so raw, I'd love to know how you felt about the other contenders that were floating about at the time. Were any of them doing things you wanted to see in BK? I can't be the only one who'd be interested in your views on the general developments for such important tools of our trade. Have you written about it anywhere? I'll pre-order "Larry walks us from SCCS to the git monoculture".

luckydude 6y ago
Actually I was part of an SCM conference put together by Facebook and Google recently. People are starting to think about what happens after Git. 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.

temporallobe 6y ago

I know Git quite well at this point in my career, but it’s still a very baffling and often frustrating SCM tool in my opinion. I find it disconcerting that despite many years with it, I still feel like I don’t totally comprehend what really is happening under the hood. There seems to be a lot of magic. I still have a sense of apprehension every time I do a rebase, and after successful conflict resolution I am surprised that it somehow worked given how messy and convoluted the rebase workflow is. One of the oddest things I more recently learned about Git is that you can’t create empty folders. The workaround is to create an empty file (e.g., a README)! That being said, entire careers are built on this powerful yet odd tool that has somehow become the most popular SCM system in the world.

scruple 6y ago
> One of the oddest things I more recently learned about Git is that you can’t create empty folders. The workaround is to create an empty file (e.g., a README)! The convention I've seen is `.keep` and `.gitkeep`.

hyperpallium2 6y ago

I so appreciate you answering questions here! I've experienced how Git's lack of file rename makes it hard to follow changes through directory and file reorganization. This made me reluctant to reorganize, as I learned the problem space. The general, long-term impact may be increased ossification pressure. OTOH linus's content addressable system is absurdly, compellingly simple, and does 90%. It's disproportionately simple. A dilemma! BTW I think many companies get killed that way. Refusing revenue to profit must be pollyanna - except for github. OTOH keeping customers is how great companies get killed, according to Christensen (the innovator's dilemma).