9 ms·

A look back: Bram Cohen vs Linus Torvalds (2007)

90 points by _qc3o 10y ago

integricho 10y ago
Is there any information on when exactly / and for what exact reasons was codeville development abandoned?
tehabe 10y ago
Not Found. Were there any interesting points mentioned?
- gcp 10y ago
  No, it's pure fanboying. The rename behavior in particular is still not a settled issue.
rincebrain 10y ago
Since this 404s for me (or, more evilly, says "200 OK" in HTTP and "Not Found" on the page), have a cache link: https://webcache.googleusercontent.com/search?q=cache:7Qj5RCqa56YJ:www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:7Qj5RC... Bonus: the two times this link showed up on HN before and got more than a couple of comments: https://news.ycombinator.com/item?id=8118817 https://news.ycombinator.com/item?id=8118817 https://news.ycombinator.com/item?id=505876 https://news.ycombinator.com/item?id=505876
- walrus 10y ago
  You probably have HTTPS Everywhere installed.
  - rincebrain 10y ago
    You would be correct. I suppose the SSL vhost is just tragically broken, then.
kbenson 10y ago
> But after closely studying Git I'm a little bit awestruck; Torvalds is a frickin' genius, a true visionary, and somehow managed to just "get it" and instantly, in a flash of insight, come up with "the solution" for version control. Wait, what? Git was the response from Torvalds to BitKeeper being proprietary and the author being upset with some kernel developers. It's basically taking what was then state of the art for DCVS and reimplementing it, not coming up with some new paradigm. It's a good program, and to my knowledge it was engineered well, but let's not rewrite history so Torvalds is the father of DVCS.
- rincebrain 10y ago
  Sort of - DVCS did not have nearly as much general uptake before Git and Mercurial caught public attention, and none of the options available met Torvalds' featureset requirements. BitKeeper existed, a few projects used darcs, GNU arch and monotone existed but I don't think I ever encountered a project using either (the Canonical arch fork aside), and that's mostly a wrap for free or Free options. He may not be the father of a novel concept which he could write a paper about, but Git and Mercurial existing certainly coincided with the enormous uptick in DVCS usage and visibility. I suppose the difference in opinion about the term "father" just comes down to being about the theory behind the problem space or wildly successful implementation, and IMO "taking known solutions and putting them together in a more successful way" is novel enough to claim credit.
  - _pmf_ 10y ago
    BitKeeper could have become GitHub + git in one entity if they made the client and hosting for FOSS free and charged for on-premises servers or private repos.
    - Swizec 10y ago
      But they didn't.
      - jacobush 10y ago
dasil003 10y ago
Were a lot of programmers really hung up on this idea of having increasingly smart merge algorithms back then? What Linus says seems self-evident to me: if there's even a whiff of a conflict, I want it to be shown to me so I can make a human decision about it. A merge algorithm smart enough to resolve every case is easily proven to be impossible by the fact that it's possible for branches to merge cleanly with no conflict, and yet still have a logical conflict due to some implicit contract that was broken. These are the nastiest regressions to find, and one reason I insist on rebasing before merging topic branches, because then at least git-bisect will tell you where the implicit contract was broken precisely on the second-rebased-and-merged branch. Smarter merge algorithms would just paper over more problems and so you quickly hit diminishing and then negative returns by trying to be too clever.
- gcp 10y ago
  You can still verify the result of an automatic merge. It's simpler to mark a suggestion "y" than to resolve conflicts that could be solved automatically by hand. So I don't think this reasoning holds any ground whatsoever.
  - andrewflnr 10y ago
    You're not actually contradicting GP. Marking a suggestion "y" is still making a human decision, just with really good auto-complete.
    - gcp 10y ago
      Look into the actual posts, it was used as an argument to dismiss smarter merge algorithms which is of course the smarter auto-complete part.
      - andrewflnr 10y ago
        What they're actually objecting to of the idea of not having a human in the loop. I suspect if you pitched these smart merge algorithms from the "click to accept auto merge" angle, they wouldn't have much of a problem. Instead they seem to be pushed as a way of avoiding interaction.
acqq 10y ago
The link to the relevant response of Linus Torvalds about his design: http://www.gelato.unsw.edu.au/archives/git/0504/2178.html http://www.gelato.unsw.edu.au/archives/git/0504/2178.html
- nicky0 10y ago
  I like this nugget from the post: "It's sometimes better to know that you don't know the answer, than it is to think that you know the answer." - Linus Torvalds
  - acqq 10y ago
    If you'd try to find the roots of that idea, it would certainly be at least hundreds of years old, reflecting the difference between the scientific and the religious approaches to the world.
    - ttctciyf 10y ago
      At least as old as Plato: "I am wiser than this man, for neither of us appears to know anything great and good; but he fancies he knows something, although he knows nothing; whereas I, as I do not know anything, so I do not fancy I do. In this trifling particular, then, I appear to be wiser than he, because I do not fancy I know what I do not know." Plato: Apology, ~ 400BC
      - acqq 10y ago
        Yes, thanks, Plato, quoting Socrates, the later defending himself https://en.wikipedia.org/wiki/Trial_of_Socrates https://en.wikipedia.org/wiki/Trial_of_Socrates for "corrupting the youth of the city-state and asebeia (impiety) against the pantheon (gods) of Athens." So my claim above that it's about the religion vs science still stays. "Science" is of course relatively modern term, the older one was "natural philosophy." https://en.wikipedia.org/wiki/Natural_philosophy https://en.wikipedia.org/wiki/Natural_philosophy
      - vacri 10y ago
qplex 10y ago
Article from 2007.
mkj 10y ago
The merge algorithm http://wiki.monotone.ca/MarkMerge/ http://wiki.monotone.ca/MarkMerge/ used by Monotone has a well defined user model for conflicts, with similarity to Codeville's merge algorithm iirc. I'm not sure if any later VCS used it, looks like perhaps not.
- tbrownaw 10y ago
  Mark-merge is specifically for standalone scalar values. We used it for tree structure (file name, and patent directory), for file attributes, and as a first pass on file content to see if we needed to bother doing a 3-way message. Tree structure is overrated. The way git handles it works better in practice. Files are an implementation detail, rather than something fundamental about code structure. Using it as a first pass at content merging was mostly a performance optimization, and also only works if you track individual files as objects. It might be a useful building block for a system that tracks refactorings as fundamental operations and knows how to do merges on your AST instead of on the serialized text form of your choice. But as far as I know no such system exists yet, and merging complex data structures is far more complex than simply merging their individual building blocks.
j1vms 10y ago
Looking at the exchange a bit and reviewing the context in which it occurred: it's a great example of someone clearly deciding what problem they want to fix, followed by defining their priorities and sticking to them. As Linux has pointed out (IIRC), doing this pointed the way toward the underlying data structures, and the algorithms to manipulate this data followed from there. Cohen, as remarkable as always, comes across in this instance as trying to "sell" his product (codeville) and taking it a little personally when Linus isn't swayed. Linus clearly defines the problem he was trying to solve, and believes that git solves it better than codeville. He would have backed codeville if he thought it met kernel dev needs better than git. After all, he had jumped on Bitkeeper before, against other people's wishes.
asmosoinio 10y ago
To anyone else wondering: "Codeville was a distributed revision control system" - https://en.wikipedia.org/wiki/Codeville https://en.wikipedia.org/wiki/Codeville
- ythn 10y ago
  Surprisingly, BitKeeper is still around somehow
- nix0n 10y ago
  Also, Bram Cohen's diff algorithm made it into Canonical's Bazaar VCS. I think some of the Cohens' other VCS ideas may have made it into Bazaar, but I'm not sure.
vacri 10y ago
Yet another description of "Linus and his fireworks", and when you actually read the thread, there's a little bit of crankiness, yes, but mostly a lot of discussion. It's milder than what goes on in a lot of HN threads. Damn people love this trope.
deleted 10y ago
[deleted]
pawadu 10y ago
This reminds me of that old discussion between Linus and ESR where the ESR tries really hard and has a lot of really good arguments but Linux doesn't care because he is right. The thread was on HN last year, I think the title was something about Linus being to smart for his own good or something similar. edit: "The curse of the gifted programmer (2000)", https://news.ycombinator.com/item?id=11077799 https://news.ycombinator.com/item?id=11077799
phkahler 10y ago
If Linus had insight into issues around merging it's because that's what he does for a living. Every change to the Linux Kernel is ultimately approved/merged by him. Think about that. More than any person on earth, Linus knew what the issues involved with DVCS were and he chose a solution that fit all the use cases he saw on a daily basis.
- yes_or_gnome 10y ago
  He's not even a top 20 approver. Greg KH takes those honors, Andrew Morton is number 3, and I forget the rest. The list comes out annually from the Linux Foundation. (Sorry, no link.) The foundation requires an email address and credentials before providing access to the pdf. During the merge window, Linus takes in most of changes for the next kernel release. All of which have been approved by someone else. With each RC release, the lieutenants still approve most of the new changes. It's a matter of when a crucial fix is needed for Linus's mainline kernel, then he'll accept a commit directly.
SadWebDeveloper 10y ago
Git is popular (nowadays), it's a decent DVCS that requires craftmanship and tons of trials and errors before you can consider yourself "pro user" and it's funny that the go to solution for all git problems it's still "just hard reset your repo".

90 points by _qc3o 10y ago

integricho 10y ago

Is there any information on when exactly / and for what exact reasons was codeville development abandoned?

tehabe 10y ago

Not Found. Were there any interesting points mentioned?

gcp 10y ago
No, it's pure fanboying. The rename behavior in particular is still not a settled issue.

rincebrain 10y ago

Since this 404s for me (or, more evilly, says "200 OK" in HTTP and "Not Found" on the page), have a cache link: https://webcache.googleusercontent.com/search?q=cache:7Qj5RCqa56YJ:www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:7Qj5RC... Bonus: the two times this link showed up on HN before and got more than a couple of comments: https://news.ycombinator.com/item?id=8118817 https://news.ycombinator.com/item?id=8118817 https://news.ycombinator.com/item?id=505876 https://news.ycombinator.com/item?id=505876

walrus 10y ago
You probably have HTTPS Everywhere installed.
- rincebrain 10y ago
  You would be correct. I suppose the SSL vhost is just tragically broken, then.

kbenson 10y ago

> But after closely studying Git I'm a little bit awestruck; Torvalds is a frickin' genius, a true visionary, and somehow managed to just "get it" and instantly, in a flash of insight, come up with "the solution" for version control. Wait, what? Git was the response from Torvalds to BitKeeper being proprietary and the author being upset with some kernel developers. It's basically taking what was then state of the art for DCVS and reimplementing it, not coming up with some new paradigm. It's a good program, and to my knowledge it was engineered well, but let's not rewrite history so Torvalds is the father of DVCS.

rincebrain 10y ago
Sort of - DVCS did not have nearly as much general uptake before Git and Mercurial caught public attention, and none of the options available met Torvalds' featureset requirements. BitKeeper existed, a few projects used darcs, GNU arch and monotone existed but I don't think I ever encountered a project using either (the Canonical arch fork aside), and that's mostly a wrap for free or Free options. He may not be the father of a novel concept which he could write a paper about, but Git and Mercurial existing certainly coincided with the enormous uptick in DVCS usage and visibility. I suppose the difference in opinion about the term "father" just comes down to being about the theory behind the problem space or wildly successful implementation, and IMO "taking known solutions and putting them together in a more successful way" is novel enough to claim credit.
- _pmf_ 10y ago
  BitKeeper could have become GitHub + git in one entity if they made the client and hosting for FOSS free and charged for on-premises servers or private repos.
  - Swizec 10y ago
    But they didn't.
    - jacobush 10y ago

dasil003 10y ago

Were a lot of programmers really hung up on this idea of having increasingly smart merge algorithms back then? What Linus says seems self-evident to me: if there's even a whiff of a conflict, I want it to be shown to me so I can make a human decision about it. A merge algorithm smart enough to resolve every case is easily proven to be impossible by the fact that it's possible for branches to merge cleanly with no conflict, and yet still have a logical conflict due to some implicit contract that was broken. These are the nastiest regressions to find, and one reason I insist on rebasing before merging topic branches, because then at least git-bisect will tell you where the implicit contract was broken precisely on the second-rebased-and-merged branch. Smarter merge algorithms would just paper over more problems and so you quickly hit diminishing and then negative returns by trying to be too clever.

gcp 10y ago
You can still verify the result of an automatic merge. It's simpler to mark a suggestion "y" than to resolve conflicts that could be solved automatically by hand. So I don't think this reasoning holds any ground whatsoever.
- andrewflnr 10y ago
  You're not actually contradicting GP. Marking a suggestion "y" is still making a human decision, just with really good auto-complete.
  - gcp 10y ago
    Look into the actual posts, it was used as an argument to dismiss smarter merge algorithms which is of course the smarter auto-complete part.
    - andrewflnr 10y ago
      What they're actually objecting to of the idea of not having a human in the loop. I suspect if you pitched these smart merge algorithms from the "click to accept auto merge" angle, they wouldn't have much of a problem. Instead they seem to be pushed as a way of avoiding interaction.

acqq 10y ago

The link to the relevant response of Linus Torvalds about his design: http://www.gelato.unsw.edu.au/archives/git/0504/2178.html http://www.gelato.unsw.edu.au/archives/git/0504/2178.html

nicky0 10y ago
I like this nugget from the post: "It's sometimes better to know that you don't know the answer, than it is to think that you know the answer." - Linus Torvalds
- acqq 10y ago
  If you'd try to find the roots of that idea, it would certainly be at least hundreds of years old, reflecting the difference between the scientific and the religious approaches to the world.
  - ttctciyf 10y ago
    At least as old as Plato: "I am wiser than this man, for neither of us appears to know anything great and good; but he fancies he knows something, although he knows nothing; whereas I, as I do not know anything, so I do not fancy I do. In this trifling particular, then, I appear to be wiser than he, because I do not fancy I know what I do not know." Plato: Apology, ~ 400BC
    - acqq 10y ago
      Yes, thanks, Plato, quoting Socrates, the later defending himself https://en.wikipedia.org/wiki/Trial_of_Socrates https://en.wikipedia.org/wiki/Trial_of_Socrates for "corrupting the youth of the city-state and asebeia (impiety) against the pantheon (gods) of Athens." So my claim above that it's about the religion vs science still stays. "Science" is of course relatively modern term, the older one was "natural philosophy." https://en.wikipedia.org/wiki/Natural_philosophy https://en.wikipedia.org/wiki/Natural_philosophy
    - vacri 10y ago

qplex 10y ago

Article from 2007.

mkj 10y ago

The merge algorithm http://wiki.monotone.ca/MarkMerge/ http://wiki.monotone.ca/MarkMerge/ used by Monotone has a well defined user model for conflicts, with similarity to Codeville's merge algorithm iirc. I'm not sure if any later VCS used it, looks like perhaps not.

tbrownaw 10y ago
Mark-merge is specifically for standalone scalar values. We used it for tree structure (file name, and patent directory), for file attributes, and as a first pass on file content to see if we needed to bother doing a 3-way message. Tree structure is overrated. The way git handles it works better in practice. Files are an implementation detail, rather than something fundamental about code structure. Using it as a first pass at content merging was mostly a performance optimization, and also only works if you track individual files as objects. It might be a useful building block for a system that tracks refactorings as fundamental operations and knows how to do merges on your AST instead of on the serialized text form of your choice. But as far as I know no such system exists yet, and merging complex data structures is far more complex than simply merging their individual building blocks.

j1vms 10y ago

Looking at the exchange a bit and reviewing the context in which it occurred: it's a great example of someone clearly deciding what problem they want to fix, followed by defining their priorities and sticking to them. As Linux has pointed out (IIRC), doing this pointed the way toward the underlying data structures, and the algorithms to manipulate this data followed from there. Cohen, as remarkable as always, comes across in this instance as trying to "sell" his product (codeville) and taking it a little personally when Linus isn't swayed. Linus clearly defines the problem he was trying to solve, and believes that git solves it better than codeville. He would have backed codeville if he thought it met kernel dev needs better than git. After all, he had jumped on Bitkeeper before, against other people's wishes.

asmosoinio 10y ago

To anyone else wondering: "Codeville was a distributed revision control system" - https://en.wikipedia.org/wiki/Codeville https://en.wikipedia.org/wiki/Codeville

ythn 10y ago
Surprisingly, BitKeeper is still around somehow
nix0n 10y ago
Also, Bram Cohen's diff algorithm made it into Canonical's Bazaar VCS. I think some of the Cohens' other VCS ideas may have made it into Bazaar, but I'm not sure.

vacri 10y ago

Yet another description of "Linus and his fireworks", and when you actually read the thread, there's a little bit of crankiness, yes, but mostly a lot of discussion. It's milder than what goes on in a lot of HN threads. Damn people love this trope.

deleted 10y ago

[deleted]

pawadu 10y ago

This reminds me of that old discussion between Linus and ESR where the ESR tries really hard and has a lot of really good arguments but Linux doesn't care because he is right. The thread was on HN last year, I think the title was something about Linus being to smart for his own good or something similar. edit: "The curse of the gifted programmer (2000)", https://news.ycombinator.com/item?id=11077799 https://news.ycombinator.com/item?id=11077799

phkahler 10y ago

If Linus had insight into issues around merging it's because that's what he does for a living. Every change to the Linux Kernel is ultimately approved/merged by him. Think about that. More than any person on earth, Linus knew what the issues involved with DVCS were and he chose a solution that fit all the use cases he saw on a daily basis.

yes_or_gnome 10y ago
He's not even a top 20 approver. Greg KH takes those honors, Andrew Morton is number 3, and I forget the rest. The list comes out annually from the Linux Foundation. (Sorry, no link.) The foundation requires an email address and credentials before providing access to the pdf. During the merge window, Linus takes in most of changes for the next kernel release. All of which have been approved by someone else. With each RC release, the lieutenants still approve most of the new changes. It's a matter of when a crucial fix is needed for Linus's mainline kernel, then he'll accept a commit directly.

SadWebDeveloper 10y ago

Git is popular (nowadays), it's a decent DVCS that requires craftmanship and tons of trials and errors before you can consider yourself "pro user" and it's funny that the go to solution for all git problems it's still "just hard reset your repo".