Date: Wed, 26 Nov 1997 04:27:34 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Paul Gardner-Stephen <gardners@joel.hld.c64.org> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Version Resolution? CVS, disk space and stuff Message-ID: <l03110700b0a1a5c8dd2f@[208.2.87.4]> In-Reply-To: <200011261007.KAA03138@joel.hld.c64.org> References: Your message of "Tue, 25 Nov 1997 10:58:22 MST." <199711251758.KAA27804@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>[re: should we have the CVS tree with *everything* in it, or a smaller one] > >Hmmm.. I personally think that 60 or 70MB (i recall thats the difference >in size, >*at most* between the full CVS, and a truncated one, for the full source >tree is a >pretty good price for a very useful development tool. Although I believe that your estimate is off by quite a bit, the storage space, per se, is only a part of the concern. If you will observe the content of a standard cvs file, you will see that a large portion of that file is old static history. Processing this information every time the cvs file is accessed is a cost that everyone (except the "current" users) bears. In many cases, to get to the head of the 2.2 branch, cvs must unroll the last year's changes and then re-apply them to generate a file that is the same as, or very similar to, the "current" head. There are also large pieces of "dead" code which are there only because an entire module was moved to a new location. So every time someone uses CVS or CVSup they pay a processing charge. Multiple times each day, my CTM generator spends hours comparing these static portions in its generation of the latest CTM deltas. >If i saw a complete CVS system for sale for $20, i'd probably recommend >it, and thats >what this equates to (60mb hdd = $20 ;) Close ... The 2.2.5 CD set is 29.95 and also includes a bunch of other useful info. My suggestion is not to get rid of the information in the cvs tree, but to reorganize it into a format which would allow (1) the optional omission of obsolete parts and (2) the recognition of invariant parts so that they could be ignored in processing. Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110700b0a1a5c8dd2f>