| |||||||||||||
The kernel and BitKeeper part waysThe kernel and BitKeeper part waysPosted Apr 7, 2005 16:06 UTC (Thu) by daniel (subscriber, #3181)In reply to: The kernel and BitKeeper part ways by TwoTimeGrime Parent article: The kernel and BitKeeper part ways
"What I don't understand is why were people were reverse engineering the BK protocol in the first place. Linus already said he would consider another tool if it would do what BK would do. No version control system appeared with the features he needed. Instead of reverse engineering the protocol why not create a replacement?"
Simple. There are three years of revision history locked up in BitKeeper repositories. That information is ours, we want it back. (In a less charitable mood I'd insert "told ya so" at this point.)
Regards,
Daniel
(Log in to post comments)
The kernel and BitKeeper part ways Posted Apr 7, 2005 17:42 UTC (Thu) by jee (subscriber, #202) [Link] But with the BKCVS gateway, that history is available, isn't it? As in, all the information the users put in there, including comments and so on.
The kernel and BitKeeper part ways Posted Apr 7, 2005 17:59 UTC (Thu) by jonabbey (subscriber, #2736) [Link] Including file renames and moves?
The kernel and BitKeeper part ways Posted Apr 7, 2005 20:24 UTC (Thu) by lm (guest, #6402) [Link] Yes, it includes file renames, go look at the data.
The kernel and BitKeeper part ways Posted Apr 8, 2005 16:45 UTC (Fri) by daniel (subscriber, #3181) [Link] "But with the BKCVS gateway, that history is available, isn't it?"
So if you have set up a BitKeeper repository for yourself (complete with "open logging") then how do you set up a BKCVS gateway from it? Oh you can't?
Regards,
Daniel
The kernel and BitKeeper part ways Posted Apr 7, 2005 21:21 UTC (Thu) by TwoTimeGrime (guest, #11688) [Link] > Simple. There are three years of revision history locked up in BitKeeper> repositories.
It's not locked up. It's been in CVS all along.
The kernel and BitKeeper part ways Posted Apr 8, 2005 16:36 UTC (Fri) by bronson (subscriber, #4806) [Link] So the ends justify the means? Careful, Daniel... If you're right, then the GPL is toast. So it's a good thing you're wrong. (and quite hypocritical it would appear...)
The kernel and BitKeeper part ways Posted Apr 8, 2005 17:07 UTC (Fri) by daniel (subscriber, #3181) [Link] "So the ends justify the means? Careful, Daniel... If you're right, then the GPL is toast."
Don't be disingenuous. There is nothing wrong with the "means" here. Reverse engineering is perfectly legal.
"So it's a good thing you're wrong."
According to you.
"(and quite hypocritical it would appear...)"
I resent that.
The kernel and BitKeeper part ways Posted Apr 8, 2005 23:26 UTC (Fri) by bronson (subscriber, #4806) [Link] Oh, I thought you were explaining why breaking bk's license agreement is justified. Typically, if a clause in a contract is illegal, the entire contract is void and must be renegotiated. I haven't read BK's license (who can keep up with the changes?) so don't know if they included language to change this. The point is, if you agree to a license, it's a bad idea to turn right around and knowingly break parts of it.
If you're ONLY justifying reverse engineering then that's OK and I take back the hypocritical stab. :)
The kernel and BitKeeper part ways Posted Apr 9, 2005 9:29 UTC (Sat) by daniel (subscriber, #3181) [Link] The point is, if you agree to a license, it's a bad idea to turn right around and knowingly break parts of it.How do you know whoever it was agreed to the license?
The kernel and BitKeeper part ways Posted Apr 10, 2005 2:09 UTC (Sun) by bronson (subscriber, #4806) [Link] Because that's the only legal way to have a copy of the software.
I suppose it's possible that you could sniff the wire while a properly licensed copy did transactions over it but that's starting to get real shaky...
The kernel and BitKeeper part ways Posted Apr 10, 2005 2:40 UTC (Sun) by daniel (subscriber, #3181) [Link] Because that's the only legal way to have a copy of the software. I suppose it's possible that you could sniff the wire while a properly licensed copy did transactions over it but that's starting to get real shaky...How do you know that the engineer did not just connect to a BitKeeper repository and try to make it talk by pure trial and error?
The kernel and BitKeeper part ways Posted Apr 13, 2005 8:38 UTC (Wed) by njhurst (guest, #6022) [Link] Particularly if that someone has a history of reverse engineering things from the outside (samba, tivo etc). I spent a little time working with tridge a long time ago and he's neither vindictive/zealotous nor is he naive when it comes to licences. I have no trouble believing him capable of doing what he did without touching the client, and I don't imagine him willingly using bitkeeper with the knowledge of the licence.
The kernel and BitKeeper part ways Posted Apr 17, 2005 17:57 UTC (Sun) by alext (guest, #7589) [Link] More recent reports show he (Tridge) didn't use BK in his reverse engineering and did not accept the license (no need as he wasn't installing or using BK) and the reports go on to point out that he is doing exactly what he did for Samba (for which he is celebrated like a hero).
The kernel and BitKeeper part ways Posted Apr 10, 2005 19:54 UTC (Sun) by smurf (subscriber, #17840) [Link] Reading the repository is simple, it's a souped-up SCCS format. Reading that isn't something the Bitkeeper people are able to notice in the first place, plus it's comparatively simple, and so is getting out the metadata. You don't need to generate test files for that, just look at any files in the Linux kernel tree.
What the reverse-engineering job obviously was about (at least from my remote-viewing crystal ball PoV) is to figure out the protocol used to pull changes form one repository into another. *That* shows up on openlogging.org, especially when you do it 100 times in a row to figure out which changes trigger which protocol events (a classic reverse engineering technique certain people should be *very* familiar with, if the rumor is to be believed).
|
|||||||||||||