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.
We also have a lot of binaries (as many binaries as text files). Having dealt with this problem for a while I have concluded that it is convenient, but not essential, to keep all binaries in source control. What I did was start with the largest RCS files and systematically moved them to a flat archive system. I use a naming scheme that combines the binary file name and its version. The majority of binaries are small and I left under source-control. Every few months I look for the largest files again to see if they should be removed. By removing the 50 largest binaries from our 10,000 file repository I cut the repository size in half. Performance is way up and there are no more time outs. Randy McCharles SMART Technologies Inc. Senior Software Developer Tel. 403.802.3347 Fax 403.229.2531 randymccharles at smarttech.com http://www.smarttech.com Bringing people and ideas together.(tm) -----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf Of Bo Berglund Sent: Monday, February 06, 2006 4:00 PM To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: Re: [cvsnt] Re: Repository TAG behavior On Mon, 6 Feb 2006 15:34:19 -0700, "Randy McCharles" <RandyMcCharles at smarttech.com> wrote: >I have seen this before and the cause appeared to be some very large binary files that were put under source control. cvsnt appears to spend an inordinate amount of time tagging these large files, which I suspect the only requirement is to add a couple of lines of RCS text to the top of the file. >Regardless, one I noticed the large binaries, I immediately took them out of source control and the tag timeout problem went away. (As did other "wait" problems such as very long checkout times.) > > That is my experience too, except we have not had any failures to date. But any operation involving one of our binary files (exe files with about 100-200 revisions) will take a *long* time, be it tag or log or anything else. It seems like CVSNT must wade through everything in the 200+ Mb RCS file to just check the log (which sits at the top of the file). Tag is the same. But we must keep all binaries that have been moved outside of our development department onto a customer just so we can pinpoint a problem without having the impossible task of: 1. Getting the sources out of CVS (this is easy) 2. Backtracking the build environment to that time (neither Borland nor Microsoft IDE systems are nearly in a version control system). 3. Build the binary that failed and start examine it. Now we just check out that particular tagged revision and start checking the complaint. So we really need binaries there. /Bo (Bo Berglund, developer in Sweden) _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs