Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Thu, 14 Jun 2007 22:55:59 +0100, Tony Hoyle <tony.hoyle at march-hare.com> wrote: >Bo Berglund wrote: >> 2) When one stores binaries (like we do), the principle is that >> normally only tagged releases should be committed. But this tends to >> be forgotten and a large number of intermediate unusable binaries (exe >> file for instance) get committed. THis in turn leads to the RCS file >> growing to a very large size on the server, which then leads to the >> slowing down of cvs operations on that module. > >It won't slow down cvs provided you're mostly on the trunk - the rcs >file is stored in reverse order so it's always faster to get newer >revisions than older ones (and always very fast to get HEAD). >Potentially if you were on a long lived branch and committed a lot of >binaries it could get slow but it's not that bad in practice. > >The biggest slowdown is when you have hundreds of tags.. they're stored >at the top and have to be read first. Well, we do that too, the files I am talking about are binaries (exe files) that have lived in CVS for about 4 years now. The exe itself is about 8 Mb (it was smaller in the past) and it gets tagged for each release and branch we make. I would think it could have more than 100 tags by now. But since the number of revisions is so high (several hundred) the RCS file has grown to a size of several hundred megabytes and it is my experience thta whenever a cvs operation involves this file it slows down considerably. Worst I think is tagging the file for some reason. And we do not use binary deltas, we use plain old binary. HTH /Bo (Bo Berglund, developer in Sweden)