Date: Fri, 2 Jun 1995 01:14:58 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: bde@zeta.org.au (Bruce Evans) Cc: FreeBSD-current@FreeBSD.ORG (FreeBSD current) Subject: Re: sup is fetching whole src tree Message-ID: <199506020814.BAA06959@gndrsh.aac.dev.com> In-Reply-To: <199506020757.RAA30881@godzilla.zeta.org.au> from "Bruce Evans" at Jun 2, 95 05:57:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> The CTM delta for the CVS tree for this "white space" action and > >> the CVS tag was 2.5 MB. > > >Feel glad you are on CTM instead of sup. For sup featchers of cvs > >it meant a 130MB sup. For suppers of /usr/src it meant 3993 files > >or something close to that (*not* the whole 120MB of the source > >tree). > > This is a good reason to switch to CTM. And I would if it handled a few more small nits I like about sup, like putting files back I blow away, or handling of modification dates, owners, etc since I am doing the tape backups of the cvs tree these features are rather important to me :-). > >I seem to recall Poul saying the ctm for src was 500K from me doing > >the white space clean. The cvs CTM delta was large due to the fact > >that a cvs tag operation adds 1 line per tag to every file that was > >tagged. > > Actually it was large because someone compressed the commitlogs. Ahhh.. well... that was a sup optimization, since the log files where getting rather large and it would be nice to have a clean set of log files between 2.0.5A and 2.0.5R to see just what we did fix I felt it to be a good idea. I plan to roll these over again ever time I tag the tree. This should help a lot with production of ``what changed'' between revsions x.y and x.z. I also rolled over a 3.5MB history file, then forgot to roll it again after creating 1.2MB of history due to the tag operation. The history file will be rolled over again at the next tag. Basically expect the same kind of stuff to happen every time I kick folks out of the tree to tag, as I need a quite time to do this type of work (even to the point for history file rolling that no one can be running a cvs update operation as that does write to the history file. I had to redo my history filter 2 times because the input file changed while I was prenning out the ``WUCG'' records from the file. > This > caused CTM to send huge diffs to create all the new .gz files and huge > diffs to truncate all the old files, about 2 * 750K altogether. The cvs > tag operation compresses very well and only produces 500K of ctm > updates. Well, you still did a heck of a lot better than David and myself who ended up bulling the whole 140MB cvs tree (44MB compressed). I was without a coherent cvs tree for 17 hours :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506020814.BAA06959>