login
Search
Linus Torvalds noted that he is away on vacation for a week, "I won't even have a computer with me, much less do any development." In parting, he noted that git is feature complete for his needs, "especially with the new diff-tree, it all pretty much does what I want, and I don't have any huge wish-list entries left." He suggested that the next step is to get kernel developers using the new tools, thus working on the usability of the front end scripts. Linus added, "maybe in a week, you guys will have made CVS go away. I hope so."
Git began as an interim solution in early April [story] to replace bitkeeper [story] until something better came along. Since that time, Linus has suggested that it will become a permanent solution [story], a userland filesystem upon which other SCM implementations are being built or adapted. Developed at furious pace, the 2.6 kernel source is already managed under git [story], with the 2.4 kernel soon to follow [story]. "It's pretty exactly a month since I started," Linus noted, then added regarding the usability work that's left, "I really think you guys can do a better job by now."
From: Linus Torvalds [email blocked] To: Git Mailing List [email blocked] Subject: I'm off for a week.. Date: Fri, 6 May 2005 16:05:06 -0700 (PDT) This is just a quick note to let people know that I'm taking a week off for vacation, and thus what I have right now in my git tree is pretty much what you'll see for the next week. I won't even have a computer with me, much less do any development. Anyway, especially with the new diff-tree, it all pretty much does what I want, and I don't have any huge wish-list entries left. Now it's more about getting people used to it, and making all the scripts nice and friendly, as far as I'm concerned. Maybe in a week, you guys will have made CVS go away. I hope so. It's pretty exactly a month since I started, and I really think you guys can do a better job by now. Linus
doesn't say much for bitkeeper
since it only took a couple of months to get everything Linus wanted...
I seem to remember it took bitkeeper "...years of development..."
git doesn't do what bitkeeper
git doesn't do what bitkeeper does. It just does what is needed for Linux development.
This doesn't say much for linus either though as he preferred tons of flamewars to a montlong bit of development when he decided in favour of bitkeeper firsthand ;-)
Back when Linus started worki
Back when Linus started working with bitkeeper, he did not yet know how a Linus-perfect SCM would work. Back then it was all CVS and the like, which promotes a very inefficient workflow for kernel development.
Using bitkeeper he found out how he would work best and distilling that experience (minus features from bitkeeper he doesn't need) we now have GIT.
Dissing bitkeeper ignores how much more productive Linus is these days. The bitkeeper chapter was necessary, if painful.
a) It would've taken Linus ma
a) It would've taken Linus maybe a couple of months at most to figure out the features he needed from an SCM. BitKeeper was used for three years.
b) Linus et al would still be using BitKeeper today if they had a choice.
Interpret that however you like.
You forget a couple of things
You forget a couple of things: Linus was not interested in writing a SCM tool. Larry created bitkeeper specifically for Linus. Linus is entitled to use any tool he wants and he continued to interoperate with users who didn't use bitkeeper by accepting patches. Anyone who thinks that bitkeeper didn't help the linux community significantly is seriously misguided and quite simply doesn't have clue. Try reading the kernel mailing list archives sometime and you'll find statements from pretty much every top developer (even those who didn't use bitkeeper personally as they didn't like the licence) saying that things had become better after Linus started using bitkeeper. And I didn't see any of the bitkeeper naysayers creating a competing system during those 3 years that worked in the way Linus wanted btw. - all they did is whine.
You forgot one thing...
things had become better after Linus started using bitkeeper.
Ever consider that no SCM was used by Linus until Bitkeeper? The situation would obviously get "better".
"Larry created bitkeeper specifically for Linus."
"Larry created bitkeeper specifically for Linus."
That is not true.
OK
How about we just git on with life?
A positive spin helps the longterm good.
Learn from the past, without entrapment therein.
Actually, no
Actually, Linus didn't even trust CVS to check in *his own* changes. He preferred to manage patches completely manually. CVS might not have been perfect, but it was a heck of a lot better than nothing, especially if only one person is doing the checking in.
What Bitkeeper did was provide Linus with enough of a luxury environment that he started to see the benefits of *any* SCM. Once he saw the benefits and how easy it was to get into the habit of using one, he got hooked.
It took much longer than 3 months for Linus to SCM hater to an SCM lover and much longer than that to figure out what he wanted. He might have taken too long to ditch Bitkeeper, but don't overrestimate the time.
Re: Actually, no
Wrong. Linus was quite aware of pre-BK SCMs, and quite aware of how inadequate they were, and are.
As we saw in the post-BK period, three years later, there is no other SCM that could handle the high volume and distributed development of the kernel.
Linus was not an SCM hater, he was simply aware that no SCM package could meet the needs of the kernel, so he simply used kernel.org as his SCM.
Free VCSs inadequate?
Linus was quite aware of pre-BK SCMs, and quite aware of how inadequate they were, and are.
You don't seem to be understanding what's going on here. Darcs, Arch and Monotone are perfectly good distributed version-control systems.
Kernel development requires a VC system optimised for huge trees (Linus' initial Git commit is 220MB of data). As there aren't many trees that large in the wild, the developers of free VCSs are not interested in optimising for that sort of usage patterns.
Since the needs of kernel development are unique, it is only natural that they should design a unique data structure and set of algorithms. Now that such code has been provided under a Free licence (and the structure of a Git repo is very interesting indeed), you can expect this technology to percolate to existing VC systems in typical Free Software manner.
Linus is lazy?
Linus is lazy?
Mercurial
I am suprised that so little attention has been paid to Mercurial, a source control backend designed by Matt Mackall, who is also a kernel developer. Mercurial stores revisions as compressed deltas, similar to BitKeeper.
Linus initially raised some objections to Mercurial's model on the git mailing list, however, in the course of the discussion Linus conceded that Mercurial satisfies all of the goals that were originally set out for git.
Mercurial accomplishes this in ~1000 lines of python code, matches the speed of git, and is estimated to use about 10x less disk space (the git repository is estimated to grow to about 3GB when the entire BK history is imported).
At the end of the discussion Linus made a vague reference to the growth of Changeset files in SCMs that use BK-like models, but I did not get the feeling that Mercurial was being considered seriously enough.
Three words: Not Invented Her
Three words: Not Invented Here
Bull$hit
You comment is BS and you know it. Linus and others have used tools developed by others for a long time. Hell, even Git uses tools created by others(rsync). If they really suffered from NIH, they would recreate those as well. And if they suffer from NIH, why did Linus suggest Monotone as an alternative to BK?
Python
Was the choice of python seen as a negative, beyond the fact that it wasn't Linus' idea?
mercurial
Developers prefer to use their own tools ;-)
I get the feeling that Linus
I get the feeling that Linus objected to SCM speed most of all. It seemed like most distributed SCMs (darcs, mercurial, arch, svk, etc.) took quite a while to import patches - to the point where Linus would be sitting around waiting for the system to import patches instead of doing productive work.
Mercurial Speed
Mercurial has been benchmarked against git, using 200 real-life patches. It is able to keep up with git.
Mercurial is newer than git
Mercurial devel started a few days after git devel started.
Probably if it had been developed a month earlier then git wouldn't have been developed.
RE: Mercurial
Personally, I dont know python, and I know C. I'd rather use something I can modify to my will if need be. Both can exist though right? Why not let people just use what they want.
Yeah both can exist, and I do
Yeah both can exist, and I don't see anything particularly wrong with git. But don't discount a python tool because you "don't know python". If you know more than one language including C, you can learn python in a few hours. It's really super-duper easy. I know plenty of people who have bugfixed or modified python tools without ever having learned any of the language. They just opened up the files and said: oh, I get it.
this does not fit with the praises to bitkeeper
given the story of tridge of the bitkeeper story and the fact that linus only needed one month to replace the missing functionality of bitkeeper i think that the statements of linus where a bit out of perspective and with to much personal involvement. Hopefully linus and tridge find a way to be friends again.
Ironically enough linus now uses partially tools made by tridge. rsync is -as far as i have seen- used with git and made by...
tridge. Sometimes history makes strange moves.
st