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.

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?

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.

- 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.

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.

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.

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

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.

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.

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

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.

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 = ) bputs(buf);
    } else {
        for (i = 1; defined(argv[i]); i++) {
            if (defined(f = fopen(argv[i], "r")) {
                while (buf = ) 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.

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.

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.

But no disrespect intended towards Richard, I've met him plenty of times and enjoyed it each time. Great guy.

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.