Having local repositories doesn't replace branches and tags (you can still use them and every local repository is its own branch).
Resolving the "open, shared access to one repository" issue is a huge deal.
With a distributed version control system, you don't have to give every developer write access to the main repository. It's great that you and I know how to branch and tag, but there are plenty of people who don't, and with a centralized repository, your choices are to take the risk of someone breaking something that you'll have to go back fix, or forcing people to go through a guru every time they want to start a new branch.
The biggest thing that Git has changed with how I use a VCS is that now I can commit with impunity.
If I'm making a big change, I can commit broken code a few times in the process. Even with a private branch in a centralized system, I don't like to commit broken code. That means that before I was losing half of the benefit of version control - leaping without a net, so to speak.
Sure... I could do that with my own branch in a centralized system (assuming I always have access to a fast and reliable network connection), but somehow I don't.
Resolving conflicts in merges is a lot easier with Git as well (as is demonstrated with the Linux kernel developers). As you said - if you work with branches, merge issues are inevitable. In addition to having better merge tools, being distributed can actually help make it easier to resolve those conflicts.
An added bonus is that if you're training someone, by the time you can get them up and running just doing commits and updates with SVN or Perforce, you can have them getting the benefits of branching with Git (on the command line, anyway; Git support is still lacking in most IDEs), and you don't have to worry about them breaking something in the trunk or (as I often see) making a ton of changes without committing.
What I'd really like to see is a version control system that commits with every save; maybe something like Time Machine with branches, tags, merges, and comments; Git isn't quite there, but it's closer than SVN or Perforce.
...that is not an issue, because I can either search for an intersection or business I am at, and then easily run a second search from there for whatever (just zoom out a little and search).
Sure you can do it... but it's an unnecessary extra step that more or less doubles the amount of time you have to spend searching for something.
The whole point of the thing is to make things easier and more convenient.
Maybe I'm just too lazy and impatient, but, as much as I love the Google Maps feature, it annoys me that just about every single time I use it I have to go through the extra legwork.
Even if the data from the cell towers just narrowed it down to within a mile or two radius, that would be more than enough given the default scale of the maps and the range of the Google local search.
I'm not saying it's not useful in its current form (I love it and it utterly destroys the alternative of calling 411), but I really don't see how you can deny that giving the iPhone a way of knowing (roughly) where you are would be a significant improvement.
I agree that the iPhone Google Map app is great (both for directions and as a better 411)... but even with the driving directions, without you have to put in your starting location.
If you're in a strange city and get a hankering for calamari, you can't just type in "seafood" and expect to get a list of restaurants without telling the phone (at least roughly) where you are (and if you don't live there, you might have trouble narrowing that down).
You don't even need full-fledged GPS either - just getting a rough location from the towers would go a long way.
If Boost can do it, I've got to think that Apple could too (and I have no doubt that they eventually will).
I think what you're missing is that even if you always know exactly where you are (which isn't reasonable to assume of everyone... or really anyone all the time), then, unless you're standing still, you've got to tell the map application.
If you stick a GPS receiver in the iPhone - even a crappy one that doesn't work that well, the iPhone can have at least some idea of where you are without you having to tell it.
Can I only check out certain branches without getting every branch it's related to?
Absolutely.
Actually... I almost mentioned that before but I wasn't sure that that was *quite* the solution for you (to the extent that it does help though, it's in there).
Thanks for the link. I agree it's pretty sad if that was a primary motivation for not importing the whole tree. Fixing that seems like it might take a significant redesign (although I imagine that there's a way that you could automatically merge incomplete histories).
It occurs to me that when you're in a bandwidth-limited situation (say on a trip with your notebook), distributed systems like Git might actually work better for you. When you have access to a high-speed connection, you can do the more expensive push/pull. When you don't, you can just rely on the local repository - even when you don't have an internet connection.
Any chance you could post a link to something that says that Linus didn't import the entire history because of bandwidth issue? Everything I could find seemed to suggest it was just the difficulty of importing the history. This really matters because If it was a technical issue, then your argument loses quite a bit of its potency.
I understand that you were speaking about archives, in general, but the kernel is a great test case considering its size and its rate of development.
You're more than welcome to use SVN if it suites you. Makes no difference to me one way or another. Heck - I still have to use it for some projects myself because integrated Eclipse support isn't there yet for Git.
All I'm saying is that you shouldn't discount Git out of hand just because of some perceived issue of bandwidth and storage without trying it out for yourself. If you're working on something modestly sized (on the order of a few megs), you could realistically do it over dialup (I wouldn't envy you, but you could do it... though, if you're the sort of person who needs version control, it seems unlikely that you'd be stuck with something as slow as dialup)
To the best of my knowledge, you are correct that every Git user has the entire history.
This is really a non-issue, though. Storage is cheap and the history doesn't take up that much space.
The 2.6 kernel takes about 285MB and the entire 2 year history is about 187MB. The initial release was in 1991 - 16 years ago. Assuming 187MB every two years (which is certainly a gross overestimate) that's still less than 3GB. Not exactly small, but not obscenely huge either by today's standards. But it's not even that bad. You can get the entire kernel bitkeeper history here in under 200MB (which is still comfortably smaller than the kernel, itself).
The repository size wasn't even the reason that Linus gave for not importing the history. If memory serves, I believe it was more of a technical issue of correctly importing the history from bitkeeper and patches.
If your goal is mediocrity and you achieve it, you've done what you set out to do.
The GP's claim was that SVN was bloody better than CVS. You're saying SVN is a replacement for CVS so it's not surprising that using SVN is about the same as CVS. You can't have it both ways.
Like SVN, Git can serve as a stand-in replacement for CVS.
Just because it's distributed doesn't mean you have to use it that way. If you wanted to, you could set up a central repository and do a "git push" every time you commit and a "git pull" to update.
But Git gives you so much more.
You get a full-fledged repository on your local machine. That means you can make changes and do commits without having to worry about breaking the code in the main repository. That might not sound like much, but it has completely changed the way I work - not because it forced me into some new use pattern, but because it enabled me to do things I wouldn't even have considered before.
Compare that with SVN where in day-to-day use, you're basically doing the same things you could have done in CVS. SVN certainly fixes things that were badly broken with CVS, but it stops there. Git lets you do everything you did before, but also lets you do things you couldn't (or shouldn't) with CVS or SVN.
You're forgetting that SVN is about 7 years old and Git is closer to 2, and (by Linus' own words) has only been in a state where end-users would be able to use it comfortably for around 6 months.
A Windows GUI and IDE support both take time. Once developed, you could use a Git version of TortoiseSVN exactly as you are now - with the additional benefit of being able to access your filing system on any of your machines even when you're not connected to a network.
I think this is just an issue of Git being too new for you at the moment. Give it another 6 months to a year to mature and see if your objections still stand.
If you're using the command line, then what I said still stands, though I'll certainly concede that the biggest weakness of Git (and my single biggest complaint) is the current lack of support in IDEs (though it is my understanding that that will change relatively soon for Eclipse).
That said, separate repositories only seem like overkill because you're used to CVS/SVN where creating separate repositories is expensive.
I tried DARCS awhile back (like you, I was awestruck by the feature set - especially distributed version control and Haskell)
It seemed dog slow even for a small repository, and was clunky to use (coming from CVS).
Like I said - this was awhile back - so maybe they've fixed those issues, but following the tutorial, I was up and running with Git in no time and the commonly used commands are more or less identical to CVS/SVN (though it is a bit idiosyncratic in that it requires something like "git commit -a" where you would normally just use "cvs/svn commit").
Sorry but in my experience it was just marginally better (and in day-to-day use, from the end-users perspective, the only real difference I felt was that I was typing "svn commit" or "svn update" instead of "cvs commit" or "cvs update").
I'm not saying there aren't cool things about SVN (like atomic commits and directories), but Subversion doesn't fundamentally change the way you work like Git.
You say "it doesn't feature distributed repositories" like that's some sort of trivial throw-away nothing. It's not.
With Git, every developer gets their own full-fledged repository (or more than one if they like). That means that every time they make a change, they can have the safety net of version control without breaking the codebase for everyone else or having to deal with annoying branching and merging.
It's also trivial to create a local repository with Git. "git init" and you're running. Sure, you can do it with CVS or SVN, but you've got to create a special directory, check your stuff in and then check it out. It might not sound like much, but that extra little barrier was enough to keep me from even considering SVN/CVS for small throw-away projects that I wouldn't hesitate to keep under version control with Git.
SVN is essentially what it claims to be - CVS done right. It's a better design and implementation, but using it still feels more or less like using CVS.
Shouldn't there have been one if it's markedly better than either CVS or Subversion?
I'd assume it's just that most people don't know about Git.
It just needs a new PR guy and a little bit of time.
The only reason I've ever heard about it is that I saw some random article here about it a few months back. I tried it on a whim, and found that it's strikingly better than SVN or CVS.
Creating repositories is trivial (and can be done in place). Merges in large groups are fast, easy, and work well. For almost everything in day-to-day use, the commands are about the same as SVN or CVS (though it does annoyingly require something like "git commit -a" instead of just "git commit").
I used to use CVS (and still do for some projects). Then I switched over to SVN. It was remarkably unremarkable.
Then, a few months ago, there was a/. article on git. It sounded interesting so I tried it... and was thoroughly impressed.
I was up and running in about 20 minutes. You can use cvs/svn like commands, *but* you get local / decentralized repositories with fast forking and merging.
Start a project. Type "git init" and you've got a repository in place (you don't have to initialize and then check it out). "git add." and "git commit" and you've got your first revision.
It took a little bit more effort to figure out how to push/pull from a remote repository, but it's fairly straightforward. A bunch of people can work in a group, have their own local repositories, and then merge their changes (along with the revision history). It's awesome.
The only reason I haven't switched all of my projects over to it is that the IDEs I use (Xcode and Eclipse) don't have good git integration (as far as I know).
It's been awhile but I have a small - but significant - correction / retraction.
After spending a fair bit of time haggling with AT&T, they reduced the fee down to include only activation ($37) and they said that they would have eliminated that but I didn't cancel my service within three days of activation.
That seems perfectly acceptable to me - especially considering that your Radio Shack prepaid phone solution would have cost close enough to that as to not be worth the bother (and, if someone was sufficiently motivated, they could have tried and cancelled the service within three days at no cost except for the time and hassle of having to deal with customer service if something gets screwed up, as it did in my case)
It's beyond me how someone would switch carriers without trying out the service first. A $20 prepaid phone from RadioShack or similar comes with like $10 worth of airtime.
Well... for starters, I wasn't even aware that that that was an option.
it's just not that hard to figure out before signing a 2-year contract
A 2 year contract... with a 2-week trial period (with which, I naively assumed I could - and follow me here - try the service).
It's really your own fault if you lost that kind of money because you aren't in a good enough service area
Yes, it is my fault. I fully admit that. I didn't read the contract in detail, I stupidly assumed that when AT&T's own site said
Q. Do you have a special return policy for iPhones?
A. Yes. Apple branded equipment is covered by a 14-day return policy and must be returned to the original point of purchase. If the Apple branded equipment is returned unopened and in the original shrink wrapping, it will be refunded back to the original payment method. Opened Apple branded equipment that is returned within 14 days will be subject to a 10% open box restocking fee. All products must be packed in their original, unmarked packaging including any accessories and manuals that shipped with the product.
that meant that there was a two week trial period with a 10% restocking fee so that I could try the phone and the service for two weeks and, if I didn't like it, pay Apple the restocking fee, and return the phone without paying connect fees and a for a month worth of crappy service that I couldn't really use.
ESPECIALLY on a phone with a restocking fee.
I was fully aware of that going in - and (when I bought the phone), I figured that it was worth 60-bucks to try the iPhone and the service out for a week or two. Seemed like a reasonable plan considering that AT&T's coverage map said that I have "good" coverage in my area.
When it turned out that 'good' coverage in my area actually meant that I couldn't even use the phone inside, I was ready to pay the restocking fee.
Except... when I took the phone back to the Apple Store, they actually decided to waive the 10% restocking fee because I had problems with network coverage.
Unfortunately, AT&T wasn't so generous.
Apparently they honor their two week trial period by charging a startup fee and a month of service to anyone foolish enough to believe their bogus return policy.
The saddest thing about the whole situation is that it really is a great phone and in about 6 months, I'll be moving and I would have very much liked to get another one, and would have gladly handed over at least a few thousand to AT&T if it weren't for this experience.
I recently purchased an iPhone, only to find that AT&T's coverage sucks where I live (their map claims it's 'good').
If this were available, I would be able to keep the iPhone as my primary phone rather than having to switch back to my old T-Mobile service and return the phone.
Slashdot Mirror
Having local repositories doesn't replace branches and tags (you can still use them and every local repository is its own branch).
Resolving the "open, shared access to one repository" issue is a huge deal.
With a distributed version control system, you don't have to give every developer write access to the main repository. It's great that you and I know how to branch and tag, but there are plenty of people who don't, and with a centralized repository, your choices are to take the risk of someone breaking something that you'll have to go back fix, or forcing people to go through a guru every time they want to start a new branch.
The biggest thing that Git has changed with how I use a VCS is that now I can commit with impunity.
If I'm making a big change, I can commit broken code a few times in the process. Even with a private branch in a centralized system, I don't like to commit broken code. That means that before I was losing half of the benefit of version control - leaping without a net, so to speak.
Sure... I could do that with my own branch in a centralized system (assuming I always have access to a fast and reliable network connection), but somehow I don't.
Resolving conflicts in merges is a lot easier with Git as well (as is demonstrated with the Linux kernel developers). As you said - if you work with branches, merge issues are inevitable. In addition to having better merge tools, being distributed can actually help make it easier to resolve those conflicts.
An added bonus is that if you're training someone, by the time you can get them up and running just doing commits and updates with SVN or Perforce, you can have them getting the benefits of branching with Git (on the command line, anyway; Git support is still lacking in most IDEs), and you don't have to worry about them breaking something in the trunk or (as I often see) making a ton of changes without committing.
What I'd really like to see is a version control system that commits with every save; maybe something like Time Machine with branches, tags, merges, and comments; Git isn't quite there, but it's closer than SVN or Perforce.
...that is not an issue, because I can either search for an intersection or business I am at, and then easily run a second search from there for whatever (just zoom out a little and search).Sure you can do it... but it's an unnecessary extra step that more or less doubles the amount of time you have to spend searching for something.
The whole point of the thing is to make things easier and more convenient.
Maybe I'm just too lazy and impatient, but, as much as I love the Google Maps feature, it annoys me that just about every single time I use it I have to go through the extra legwork.
Even if the data from the cell towers just narrowed it down to within a mile or two radius, that would be more than enough given the default scale of the maps and the range of the Google local search.
I'm not saying it's not useful in its current form (I love it and it utterly destroys the alternative of calling 411), but I really don't see how you can deny that giving the iPhone a way of knowing (roughly) where you are would be a significant improvement.
I agree that the iPhone Google Map app is great (both for directions and as a better 411)... but even with the driving directions, without you have to put in your starting location.
If you're in a strange city and get a hankering for calamari, you can't just type in "seafood" and expect to get a list of restaurants without telling the phone (at least roughly) where you are (and if you don't live there, you might have trouble narrowing that down).
You don't even need full-fledged GPS either - just getting a rough location from the towers would go a long way.
If Boost can do it, I've got to think that Apple could too (and I have no doubt that they eventually will).
I think what you're missing is that even if you always know exactly where you are (which isn't reasonable to assume of everyone... or really anyone all the time), then, unless you're standing still, you've got to tell the map application.
If you stick a GPS receiver in the iPhone - even a crappy one that doesn't work that well, the iPhone can have at least some idea of where you are without you having to tell it.
In short - iPhone's maps + GPS would "Just Work".
Absolutely.
Actually... I almost mentioned that before but I wasn't sure that that was *quite* the solution for you (to the extent that it does help though, it's in there).
Thanks for the link. I agree it's pretty sad if that was a primary motivation for not importing the whole tree. Fixing that seems like it might take a significant redesign (although I imagine that there's a way that you could automatically merge incomplete histories).
It occurs to me that when you're in a bandwidth-limited situation (say on a trip with your notebook), distributed systems like Git might actually work better for you. When you have access to a high-speed connection, you can do the more expensive push/pull. When you don't, you can just rely on the local repository - even when you don't have an internet connection.
Any chance you could post a link to something that says that Linus didn't import the entire history because of bandwidth issue? Everything I could find seemed to suggest it was just the difficulty of importing the history. This really matters because If it was a technical issue, then your argument loses quite a bit of its potency.
I understand that you were speaking about archives, in general, but the kernel is a great test case considering its size and its rate of development.
You're more than welcome to use SVN if it suites you. Makes no difference to me one way or another. Heck - I still have to use it for some projects myself because integrated Eclipse support isn't there yet for Git.
All I'm saying is that you shouldn't discount Git out of hand just because of some perceived issue of bandwidth and storage without trying it out for yourself. If you're working on something modestly sized (on the order of a few megs), you could realistically do it over dialup (I wouldn't envy you, but you could do it... though, if you're the sort of person who needs version control, it seems unlikely that you'd be stuck with something as slow as dialup)
To the best of my knowledge, you are correct that every Git user has the entire history.
This is really a non-issue, though. Storage is cheap and the history doesn't take up that much space.
The 2.6 kernel takes about 285MB and the entire 2 year history is about 187MB. The initial release was in 1991 - 16 years ago. Assuming 187MB every two years (which is certainly a gross overestimate) that's still less than 3GB. Not exactly small, but not obscenely huge either by today's standards. But it's not even that bad. You can get the entire kernel bitkeeper history here in under 200MB (which is still comfortably smaller than the kernel, itself).
The repository size wasn't even the reason that Linus gave for not importing the history. If memory serves, I believe it was more of a technical issue of correctly importing the history from bitkeeper and patches.
If your goal is mediocrity and you achieve it, you've done what you set out to do.
The GP's claim was that SVN was bloody better than CVS. You're saying SVN is a replacement for CVS so it's not surprising that using SVN is about the same as CVS. You can't have it both ways.
Like SVN, Git can serve as a stand-in replacement for CVS.
Just because it's distributed doesn't mean you have to use it that way. If you wanted to, you could set up a central repository and do a "git push" every time you commit and a "git pull" to update.
But Git gives you so much more.
You get a full-fledged repository on your local machine. That means you can make changes and do commits without having to worry about breaking the code in the main repository. That might not sound like much, but it has completely changed the way I work - not because it forced me into some new use pattern, but because it enabled me to do things I wouldn't even have considered before.
Compare that with SVN where in day-to-day use, you're basically doing the same things you could have done in CVS. SVN certainly fixes things that were badly broken with CVS, but it stops there. Git lets you do everything you did before, but also lets you do things you couldn't (or shouldn't) with CVS or SVN.
You're forgetting that SVN is about 7 years old and Git is closer to 2, and (by Linus' own words) has only been in a state where end-users would be able to use it comfortably for around 6 months.
A Windows GUI and IDE support both take time. Once developed, you could use a Git version of TortoiseSVN exactly as you are now - with the additional benefit of being able to access your filing system on any of your machines even when you're not connected to a network.
I think this is just an issue of Git being too new for you at the moment. Give it another 6 months to a year to mature and see if your objections still stand.
If you're using the command line, then what I said still stands, though I'll certainly concede that the biggest weakness of Git (and my single biggest complaint) is the current lack of support in IDEs (though it is my understanding that that will change relatively soon for Eclipse).
That said, separate repositories only seem like overkill because you're used to CVS/SVN where creating separate repositories is expensive.
I tried DARCS awhile back (like you, I was awestruck by the feature set - especially distributed version control and Haskell)
It seemed dog slow even for a small repository, and was clunky to use (coming from CVS).
Like I said - this was awhile back - so maybe they've fixed those issues, but following the tutorial, I was up and running with Git in no time and the commonly used commands are more or less identical to CVS/SVN (though it is a bit idiosyncratic in that it requires something like "git commit -a" where you would normally just use "cvs/svn commit").
Sorry but in my experience it was just marginally better (and in day-to-day use, from the end-users perspective, the only real difference I felt was that I was typing "svn commit" or "svn update" instead of "cvs commit" or "cvs update").
I'm not saying there aren't cool things about SVN (like atomic commits and directories), but Subversion doesn't fundamentally change the way you work like Git.
You say "it doesn't feature distributed repositories" like that's some sort of trivial throw-away nothing. It's not.
With Git, every developer gets their own full-fledged repository (or more than one if they like). That means that every time they make a change, they can have the safety net of version control without breaking the codebase for everyone else or having to deal with annoying branching and merging.
It's also trivial to create a local repository with Git. "git init" and you're running. Sure, you can do it with CVS or SVN, but you've got to create a special directory, check your stuff in and then check it out. It might not sound like much, but that extra little barrier was enough to keep me from even considering SVN/CVS for small throw-away projects that I wouldn't hesitate to keep under version control with Git.
SVN is essentially what it claims to be - CVS done right. It's a better design and implementation, but using it still feels more or less like using CVS.
That is an excellent point (and a damn shame).
I'd assume it's just that most people don't know about Git.
It just needs a new PR guy and a little bit of time.
The only reason I've ever heard about it is that I saw some random article here about it a few months back. I tried it on a whim, and found that it's strikingly better than SVN or CVS.
Creating repositories is trivial (and can be done in place). Merges in large groups are fast, easy, and work well. For almost everything in day-to-day use, the commands are about the same as SVN or CVS (though it does annoyingly require something like "git commit -a" instead of just "git commit").
I used to use CVS (and still do for some projects). Then I switched over to SVN. It was remarkably unremarkable.
Then, a few months ago, there was a /. article on git. It sounded interesting so I tried it... and was thoroughly impressed.
I was up and running in about 20 minutes. You can use cvs/svn like commands, *but* you get local / decentralized repositories with fast forking and merging.
Start a project. Type "git init" and you've got a repository in place (you don't have to initialize and then check it out). "git add ." and "git commit" and you've got your first revision.
It took a little bit more effort to figure out how to push/pull from a remote repository, but it's fairly straightforward. A bunch of people can work in a group, have their own local repositories, and then merge their changes (along with the revision history). It's awesome.
The only reason I haven't switched all of my projects over to it is that the IDEs I use (Xcode and Eclipse) don't have good git integration (as far as I know).
Tell that to a room full of biologists.
Just to be pedantic - Escherichia coli (italicized; yes it matters!)
It's been awhile but I have a small - but significant - correction / retraction.
After spending a fair bit of time haggling with AT&T, they reduced the fee down to include only activation ($37) and they said that they would have eliminated that but I didn't cancel my service within three days of activation.
That seems perfectly acceptable to me - especially considering that your Radio Shack prepaid phone solution would have cost close enough to that as to not be worth the bother (and, if someone was sufficiently motivated, they could have tried and cancelled the service within three days at no cost except for the time and hassle of having to deal with customer service if something gets screwed up, as it did in my case)
Well... for starters, I wasn't even aware that that that was an option.
it's just not that hard to figure out before signing a 2-year contractA 2 year contract... with a 2-week trial period (with which, I naively assumed I could - and follow me here - try the service).
It's really your own fault if you lost that kind of money because you aren't in a good enough service areaYes, it is my fault. I fully admit that. I didn't read the contract in detail, I stupidly assumed that when AT&T's own site said
that meant that there was a two week trial period with a 10% restocking fee so that I could try the phone and the service for two weeks and, if I didn't like it, pay Apple the restocking fee, and return the phone without paying connect fees and a for a month worth of crappy service that I couldn't really use.
ESPECIALLY on a phone with a restocking fee.I was fully aware of that going in - and (when I bought the phone), I figured that it was worth 60-bucks to try the iPhone and the service out for a week or two. Seemed like a reasonable plan considering that AT&T's coverage map said that I have "good" coverage in my area.
When it turned out that 'good' coverage in my area actually meant that I couldn't even use the phone inside, I was ready to pay the restocking fee.
Except... when I took the phone back to the Apple Store, they actually decided to waive the 10% restocking fee because I had problems with network coverage.
Unfortunately, AT&T wasn't so generous.
Apparently they honor their two week trial period by charging a startup fee and a month of service to anyone foolish enough to believe their bogus return policy.
The saddest thing about the whole situation is that it really is a great phone and in about 6 months, I'll be moving and I would have very much liked to get another one, and would have gladly handed over at least a few thousand to AT&T if it weren't for this experience.
Oh well... caveat emptor, I guess.
I'll second that.
I just wish AT&T's network coverage wasn't crap where I live so I wouldn't have had to return it... and still be charged $110 for the privilege.
Indeed
For those who haven't tried it, download and install iPod Linux sometime.
Nothing else will give you such an appreciate for the time and effort Apple put into the thing.
I recently purchased an iPhone, only to find that AT&T's coverage sucks where I live (their map claims it's 'good').
If this were available, I would be able to keep the iPhone as my primary phone rather than having to switch back to my old T-Mobile service and return the phone.
I can't stop laughing :D
That's funny. I could have sworn I heard him talk about it in the WWDC 2007 keynote and that there was a bar for it in the performance graph for Safari 3