7 ms·

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 yo

by 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.
- ymbeld 6y ago
  > 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. Oh my oh my.
  - luckydude 6y ago
    Believe me, I would do backflips if someone wanted the BK source base, it's got almost 2 decades of my work in it, north of 140 man years. It's a lot to just let fade away. But I assembled a team of people better and smarter than me, I did my best to keep the code simple but I didn't always succeed. If you, or anyone, wants to pick it up, I'm happy to answer questions.
    - mucholove 6y ago
      Will take a look at it. At this point, the trick to creating a sizable git alternative I think is to Trojan horse coding into a new realm with “no-code” like apps. One of my favorites is Fossil by Richard Hipp. I wonder what your thoughts on it are. I think it is RCS, but usability wise I think it’s way ahead of git. I just recently learned C and I really like the coding style Hipp uses as well. :)
      - luckydude 6y ago
        Richard is awesome. He also did sqlite. As for Fossil, I'm a fan of his UI and code, but haven't looked in detail at the design. I'm pretty sure it is patch based with everything stored in sqlite. It's an OK way of doing things but not if you understand a weave. But no disrespect intended towards Richard, I've met him plenty of times and enjoyed it each time. Great guy.
- JNRowe 6y ago
  Thanks, although I think you're demonstrating here and in the other comments why you should write a real history. Was the conference recorded? I've tried searching, but I'm not turning anything up. As an outsider you get my worthless full agreement on strictness of history, and on solving the monorepo or vendoring dilemmas. My employer at the time of the upheaval was a bitmover customer, and as we slowly switched away one repo at a time it definitely felt like a sideways step. I'd hesitate to say backwards because it did come with some big process improvements for us, but definitely not forwards. I'd surely have been proud of solving problems with the quality that BK did too. I remember playing with a lot of the open source systems of the time¹, and none of them were in the same league. I'll make no apologies for this sounding like truly weird fan mail. ¹ I'm remembering hg, darcs, monotone, $some_implementation_of_arch, prcs, codeville but there was a lot of people in the space to some degree.

by JNRowe 6y ago

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.

ymbeld 6y ago
> 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. Oh my oh my.
- luckydude 6y ago
  Believe me, I would do backflips if someone wanted the BK source base, it's got almost 2 decades of my work in it, north of 140 man years. It's a lot to just let fade away. But I assembled a team of people better and smarter than me, I did my best to keep the code simple but I didn't always succeed. If you, or anyone, wants to pick it up, I'm happy to answer questions.
  - mucholove 6y ago
    Will take a look at it. At this point, the trick to creating a sizable git alternative I think is to Trojan horse coding into a new realm with “no-code” like apps. One of my favorites is Fossil by Richard Hipp. I wonder what your thoughts on it are. I think it is RCS, but usability wise I think it’s way ahead of git. I just recently learned C and I really like the coding style Hipp uses as well. :)
    - luckydude 6y ago
      Richard is awesome. He also did sqlite. As for Fossil, I'm a fan of his UI and code, but haven't looked in detail at the design. I'm pretty sure it is patch based with everything stored in sqlite. It's an OK way of doing things but not if you understand a weave. But no disrespect intended towards Richard, I've met him plenty of times and enjoyed it each time. Great guy.
JNRowe 6y ago
Thanks, although I think you're demonstrating here and in the other comments why you should write a real history. Was the conference recorded? I've tried searching, but I'm not turning anything up. As an outsider you get my worthless full agreement on strictness of history, and on solving the monorepo or vendoring dilemmas. My employer at the time of the upheaval was a bitmover customer, and as we slowly switched away one repo at a time it definitely felt like a sideways step. I'd hesitate to say backwards because it did come with some big process improvements for us, but definitely not forwards. I'd surely have been proud of solving problems with the quality that BK did too. I remember playing with a lot of the open source systems of the time¹, and none of them were in the same league. I'll make no apologies for this sounding like truly weird fan mail. ¹ I'm remembering hg, darcs, monotone, $some_implementation_of_arch, prcs, codeville but there was a lot of people in the space to some degree.