luckydude

Rick saying "I worked on BK" is the understatement of the century. He showed up and looked at my code, I had done things in a way that you could have walked the weave and extract any number of versions at the same time. He was really impressed with that. I split apart stuff that Rick had not seen before.

Then he proceeded to fix my code over and over again. I had a basic understanding of SCCS but Rick understood the details.

Rick knows more about SCM than any guy I know.

And he is right, SCCS is not well understood and BK even less so.

I fished today, 3 halibut. Fish tacos for the win! If you cook halibut, be warned that you must take it off at 125 degrees, let it get above that and it turns to shoe leather.

I don't like cheaters. If Tridge had done what he said he did, go him, I'm all for people being smart and figuring stuff out. But that is not what he did and it disgusts me that he pretends it is.

There is absolutely zero chance he figured out the pull protocol via telnet. I will happily pay $10,000 to anyone could do that with zero access to BK. Can't be done. If I'm wrong, I'll pay up. But I'll have a lot of questions that can't be answered.

So he cheated, he got Linus to run BK commands at his house and he snooped the network. He had no legal access to those bytes. Without those snoops, no chance he reverse engineered it.

As I have seen over and over, when the open source people want something, they will twist themselves in knots to justify getting it, legality be damned.

How about you be better than this and admit that open source is not without its skeletons?

This is completely untrue. There is no way that you could make a BK clone by telneting to a BK and running commands. Those commands don't tell you the network protocol, they show you the results of that protocol but show zero insight into the protocol.

Tridge neglected to tell people that he was snooping the network while Linus was running BK commands when Linus was visiting in his house. THAT is how he did the clone.

The fact that you all believe Tridge is disappointing, you should be better than that.

The fact that Tridge lied is disappointing but I've learned that open source people are willing to ignore morals if it gets them what they want. I love open source, don't love the ethics. It's not just Tridge.

My issues with Git

- No rename support, it guesses

- no weave. Without going into a lot of detail, suppose someone adds N bytes on a branch and then that branch is merged. The N bytes are copied into the merge node (yeah, I know, git looks for that and dedups it but that is a slow bandaid on the problem).

- annotations are wrong, if I added the N bytes on the branch and you merged it, it will (unless this is somehow fixed now) show you as the author of the N bytes in the merge node.

- only one graph for the whole repository. This causes multiple problems: A) the GCA is the repository GCA, it can be miles away from the file GCA if there was a graph per file like BitKeeper has. B) Debugging is upside down, you start at the changeset and drill down. In BitKeeper, because there is a graph per file, let's say I had an assert() pop. You run bk revtool on that file, find the assert and look around to see what has changed before that assert. Hover over a line, it will show you the commit comments to the file and then the changeset. You find the likely line, double click on it, now you are looking at the changeset. We were a tiny company, we never hit the claimed 25 people, and we supported tons of users. This form of debugging was a huge, HUGE, part of why we could support so many people. C) commit comments are per changeset, not per file. We had a graphic check in tool that walked you through the list of files, showed you the diffs for that file and asked you to comment. When you got the the ChangeSet file, now it is asking you for what Git asks for comments but the diffs are all the file names followed by what you just wrote. It made people sort of uplevel their commit comments. We had big customers that insisted the engineers use that tool rather a command line that checked in everything with the same comment.

- submodules turned Git into CVS. Maybe that's been redone but the last time I looked at it, you couldn't do sideways pulls if you had submodules. BK got this MUCH closer to correct, the repository produced identical results to a mono repository if all the modules were present (and identical less whatever isn't populated in the sparse case). All with exactly the same semantics, same functionality mono or many repos.

- Performance. Git gets really slow in large repositories, we put a ton of work into that in BitKeeper and we were orders of magnitude faster for things like annotate.

In summary, Git isn't really a version control system and Linus has admitted it to me years ago. A version control system needs to faithfully record everything that happened, no more or less. Git doesn't record renames, it passes content across branches by value, not by reference. To me, it feels like a giant step backwards.

Here's another thing. We made a bk fast-export and a bk fast-import that are compatible with Git. You can have a tree in BK, have it updated constantly, and no matter where in the history you run bk fast-export, you will get the same repository. Our fast-export is idempotent. Git can't do that, it doesn't send the rename info because it doesn't record that. That means we have to make it up when doing a bk fast-import which means Git -> BK is not idempotent.

I don't expect to convince anyone of anything at this point, someone nudged, I tried. I don't read hackernews any more so don't expect me to defend what I said, I really don't care at this point. I'm happier away from tech, I just go fish on the ocean and don't think about this stuff.

It might not have happened if it wasn't for me and avb. I need to write that up but the short story is that FDDI was the path to 100mbit, I wanted 100Mbit ethernet, the sun hardware engineers thought I wanted to signal over copper the same way that 10mbit did.

I didn't care about that, I cared about what someone in this thread said, it's amazing that you can plug a 10Mbit hub in and have it work with 100mbit, Gbit, etc.

In my mind, it was all about the packet format, if they are the same then we get cheap switches. And that is what we have today, I saw this coming around 1990.

And for you guys hating on the 1500 bytes, the SGI memory interconnect taught me that bigger is not better. When you are doing cache misses remotely, big is not good. I'm doing a shit job explaining but there is some value in smaller.

If you guys want, I'll try and write it up.

Tim was cool, he said add "The Perl logo is a trademark of O'Reilly Media and is used with permission" and we're good. Now I have to remember how to get into that VM :-)

I think the most productive thing I could do is write up how the weave works. People don't seem to understand that, if they did, nobody would be talking about patches.

I'm sorry if I pissed off the other guy, but I'm retired, and I'm tired, and I have no interest in arguing with people who don't get it. But it's on me to provide the info that lets them get it. I'll do that and what people do with it is up to them.

Pretty sure Tim doesn't care but I'll track him down and ask.

Edit: sent an email to him, we'll see.

I've built two commercially successful systems, NSElite that was used to develop the Solaris kernel and was productized as Avocet/CodeManager/TeamWare (don't blame me, I didn't name it), and BitKeeper which was, at one point, in use on every continent other than the Arctic. If you are running on a 5 year old Intel CPU, that was developed using BitKeeper.

The comment that RCS scales for binaries couldn't be more wrong, RCS hates binaries with a passion.

The fact that you didn't address any of the points I raised says you either don't understand what a weave file format is, or, you do, you recognize it is a much better format but don't want to talk about that.

This part of this thread reminds of something Ron Minnich once said: "Don't worry about people stealing your ideas, you are going to have to cram them down their throats".

I'll drop it, we can revisit when I write up how weaves work. I don't think any objective person would argue that a patch based system is as good, let alone better.

Who owns it? OReilly?

I sort of agree with this. I'm not a lisp fan, I don't think lisp is bad, it's just not how my brain works so I struggle. But I understand lisp enough to agree with you and I think that is what John was trying to do.

I just realized I didn't give credit to all the people who worked on Little. So here goes. Tim Daly did the first pass. Oscar Bonilla stepped up, I still remember him saying to Tim "we need an AST" and Tim said I can do this. We needed an AST, Oscar was right about that and a lot of other things. Rob Netzer, my roommate from college and former Brown tenured prof, he did the most heavy lifting in the Little compiler. Damon Courtney was our GUI guy, he had huge influence in Little.

Jeff Hobbs from the tcl community helped as well. I have pictures of that group of people. Jeff helped a lot, he wanted this, I could say why but I don't want to speak for him.

Little is what I'd like C to be but those guys made it happen.

I'm amazed that Little got some traction, happy that it did for a moment, those guys deserve all the credit, I was a whiny dude wanted a more C like thing and they gave it to me.

Little returns undef for OOB and for in bounds not set. Tcl returns "" for both.

The thing that GP was asking for, an OOB error, is not a thing in a language where there are no bounds.

I think if you are asking this question either I have completely failed to explain why weaves are cool or you haven't read what I said about why weaves are cool.

Patch based systems are idiotic, that's RCS, that is decades old technology that we know sucks (I've had a cocktail, it's 5pm, so salt away).

Do you understand the difference between pass by reference and pass by value? You must, but in case you don't, you can pass by reference in sizeof(void *), 4-8 bytes. Pass by value and you are copying sizeof(whatever it is you are passing) onto the stack. Obviously, pass by reference is immensely faster.

But in SCM, it isn't just about speed (and space), it's about authorship. In a patch based systems, imagine that there is user A who is doing all the work on the trunk, there is user B who is doing all the work on a branch, and then there is user U who is merging the branch to the trunk. Lets say B added a bunch of work on the branch, it all automerged. U did the merge. In a patch based system, all of the B work is going to be copied (passed by value) to the trunk and the authorship of that work will change from B to U (since U did the merge).

Flip forward to a month from now, the code has paniced or asserted, whatever, B's code on the trunk took a crap. And people are running git blame to see who did that and who did it, U did. But U didn't, B did but U merged it and it was a copy so it looks like U did it.

That's just the SCM being dishonest because it has no choice, it is pass by value.

Weaves are pass by reference. If you merged in BitKeeper and it automerged, you run blame (we call it annotate but I should make blame be an alias if I haven't already, I'm the guy that came up with blame as that verb), you would only see A and B as the authors.

Weaves mean authorship is correct and that whole repack nonsense that Git does? Yeah, that goes away, you are passing every thing by reference so there is only one copy of the code no matter how many branches it has been merged from/to.

Anyone who is pushing a patch based system (and Git is one as well) just doesn't have a clue about how to do source management. Maybe something better than a weave will come along (and if it does, rbsmith will do it, that guy bug fixed my crappy weave implementation) but I think it will just be a better weave with new operators like MOVE (current weaves know INSERT and DELETE, that's it).

Sorry if I'm being a dick, not looking for sympathy but I've got health problems, my feet hurt like crazy and I get kind of terse at the end of the day. If you truly want to understand more, and this goes for all of hacker news, I'm happy to get on a zoom call and talk this stuff through. And it is blindingly obvious I need to write up the SCCS weave and I will do so, you guys have inspired this 58 year old, burned out, can't code to save his life, dude to at least try and pass on some knowledge. I would love to be working with some young person who has some juice and pass on what I know. I don't know everything about SCM but I know a lot. I'm done, it's time for someone else to carry things forward, I'll help if you want. The world deserves a better answer than what we have now.

I wrote most of my first source management system (NSElite, mentioned elsewhere in this thread) in perl4. I was learning perl at the time and my first and second efforts were awful. Perl really lets you get sloppy and create unmaintainable code.

My 3rd rewrite was very stylized and, I felt, maintainable. Which proved to be true as I had to fix bugs in it.

I did weird stuff like using $whatever as the index into the @whatever array.

But I digress. On the <>, Little has argv so you can do

int main(string argv[]) { int i; string buf; FILE f;

    if (defined(argv[1]) && streq(argv[1], "-") && !defined(argv[2])) {
        while (buf = <STDIN>) bputs(buf);
    } else {
        for (i = 1; defined(argv[i]); i++) {
            if (defined(f = fopen(argv[i], "r")) {
                while (buf = <f>) puts(buf);
                fclose(f);
            } else {
                 fprintf(stderr, "unable to open '%s'\n", argv[i]);
            }
        }
    }
    return (0);

but why would you want to when all of that is

int main(string argv[]) { string buf;

    while (buf = <>) puts(buf);
    return (0);

I mean, come on, that's cat(1) in 8 lines of code.

edit: I need to learn hacker markup. My code looks like crap.

You are kind of making my point. In tcl, they'd just give you "", but you can't tell the difference between "past the end of the array" or an element where you said

set foo[i] = ""

In Little you can tell, we'll return undef (your clear "error" though in these languages it is a supported feature, not an error). So we support the auto expanding array but give you that extra bit of info that you are past the end.

You seem bound and determined to not hear that tcl auto expands arrays as needed. There are no bounds. So there is no error to catch.

We just thought it would be clever to return undef if you were out of bounds, which tcl code would see as "" which is what you'd get in tcl. But Little code could actually tell you are past the end.

In my mind, which many have argued isn't the best, it's a reasonable design.

You keep trying to push backwards to a design point where arrays are fixed in size at declaration and that is not how tcl (or Little) works.

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.

I don't see the array access as any different than a null pointer dereference, in both cases you are asking for something that isn't there.

In Tcl, stuff just gets auto expanded on assignment and returns "" (I think) on dereference. We chose to return undef. I'm not sure what the problem is.

That was me as well, though I wrote it in perl4 and C. My version was called NSElite. The Solaris kernel was developed under NSElite, some stuff is here:

http://mcvoy.com/lm/nselite

2000.txt documents the first 2000 resyncs (think bk pull) of the kernel.

Avocet was what you got when you took all my perl code and handed it to the tools group and they rewrote it in C++ (which they later admitted was a horrible idea). The only thing of mine that they kept was smoosh.c and that was because not a single one of them had the chops to write that code (yeah, there was no love lost between me and the tools group).

BitKeeper is what Avocet could have been if Sun had not stopped me from doing any more work on NSElite (I was 1 guy who was coding circles around 8 tools people and they didn't like it). Shrug. C++ was just wrong, perl4 was just way faster to code in, and when I needed performance I coded in C. It's not my fault they picked the wrong way to go about things. (That, BTW, was the first time I ever personally saw that you really can have one guy who can do the work of 8, almost, but not quite a 10x programmer :-)

In Tcl, everything is a string. The string rep of undef is "" so Tcl gets "" but doesn't know that it is undef.

So yeah, there is some sloppiness there. Tcl tends to use "" as sort of a null or undef so lots of stuff just works but no promises on that.

This is sloppy simply because the Tcl die hards (are there any left?) refused to see the value of undef, a value for a variable that said there is no value. We used it all over the place, there clearly is value. They didn't see that, Little never got pushed back into the Tcl source base so Tcl never thought about undef.

It is what it is, we live in an imperfect world. I tried.

Without providing an example of how to do it better, I'm not sure I see your point. Yeah, I see the problem you point out.

Consider

char *p = 0;

some complicated code that should have set p but didn't...

char c = *p; // SEGV

So do you have a way to push that error all the way back to wherever you think it should be pushed?

http://www.tcl.tk/man/tcl8.5/TclCmd/upvar.htm

That man page isn't the most clear. upvar gives you a way to modify a variable in the calling context (and I think it can go up more than one stack frame).

It's a way to pass by reference rather than the default pass by value (how tcl passes is more complicated than that for performance but the default semantics are pass by value).

We obviously liked it because upvar is how Little passes by reference. I don't know why someone thought upvar was bad, it is useful.

I would think so but I haven't done it. People embed tcl all the time, perl/tk is perl with a tcl interpreter embedded just so they can get at the tk part (gui stuff).

I think it was recorded, I'll go look.

Apologize for saying BK is quality? None needed, we prided ourselves on producing a quality product. And great support, our average response time, 24x7, was 24 minutes. It was only that "slow" because we were North America based. If you only considered the US work week, response time was usually under 2 minutes, but that's not reasonable because we had customers all over the world.

I'm gonna start with a write up of the SCCS weave, with a goal that it is enough of a spec that you could go implement it. Maybe add some notes about how I did it because the way I did it was unusual and had the side benefit that you could extract the GCA, left tip, and right tip for a merge in one pass.

I remember Pike, I looked at it. It was too far away from C for me. I'm a died in the wool C programmer (I started as a kernel programmer and formed some strong opinions there). I get that C is not for everyone but for me, it's enough of a language to do what I want and not filled with this, that, and the other kitchen sink.

So Little looks a lot more like C than Pike does. And I like it that way. It's not for everyone but C programmers will probably like it.

It's based on patches. I'm perhaps not going to win any friends, but I think that is ill-advised. Patches are great for emailing around, they are a horrible idea for an SCM.

Perhaps I need to write up how weaves work in more detail. Once you get that, you won't want an SCM based on anything else.

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.