Hello Luis, >> I know but it shouldn't matter. >>
LL> Don't get your point. Well if http://gems.rubyforge.org is the default for --source the operation should be exactly the same if i use or leave the option. >> >> In terms of performance rubygems sucks huge at the moment. >> With more then 3000 gems and 13000 versions we need a lot of >> improvements. >> LL> Mmm, I hardly understand your point, issued the same command here and LL> got ackbar spec results in 2 seconds... even with the bulk update... LL> and on Windows. Okay how much data was transfered? I'm not interested in seconds i'm sure it is the data transfer size that kills the performance it. How much data is transfered? At the moment on my system everything seems to be impossible to install anything. Just because every simple command wants to update my fucking local cache, even when i don't see a technical reason why it needs to be updates. For example installing a gem where i give the exact version number. This should just do a http request download a gem file and unpack this in the correct places. Where does it need any information about other gems? So why is it trying to do a 10min bulk update? Mostly the connection is getting a time out anyway, so even waiting is impossible. And it tries to do this on every second or third operation? Even if i just did a remote listing (with --all --details) just before this operation (which should have send enough information for the rubygems client). Well when i think i really don't understand why we should have a local cache for ruby gems at. I don't see any real value. It just adds overload and complexity. So can you tell me what the purpose of the local cache is and keeping any information locally other the local downloaded gem archive files? -- Best regards, Lothar Scholz mailto:[EMAIL PROTECTED] _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
