Date: Thu, 14 Mar 2002 18:15:50 -0800 From: Peter Wemm <peter@wemm.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <20020315021550.B8F8F38CC@overcee.wemm.org> In-Reply-To: <xzpwuweu9tm.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > Peter Wemm <peter@wemm.org> writes: > > val-tags is a useful feature (even if flawed) > > Please - and I mean this question seriously - explain to me what value > it has, because I sure can't figure it out. Somebody got annoyed enough that a typo on a tag removed every file from the client, so cvs got modified to actively look for tags before "activating them". peter@freefall[5:43pm]~/work/ls-107> ls CVS/ cmp.c lomac.c ls.1 ls.h util.c Makefile extern.h lomac.h ls.c print.c peter@freefall[5:43pm]~/work/ls-108> cvs up -r RELNG_4 cvs [update aborted]: no such tag RELNG_4 In this case, it searched every file in src/bin/ls/* (and any descendants if they existed) and conclusively found that RELNG_4 didn't exist, and therefore it wasn't going to switch my client to that incorrect tag. But that would be slow if it had to recursively search for RELENG_4 each time you did a 'cvs up -r RELENG_4' in /usr/src, so they added a cache. I do not recall whether it aborts the search on the first match, or if it searches everything. I believe it is the latter (ie: if there is no val-tags match, it will search the entire tree). Once the client validates a tag by searching for it, it stores it in the val-tags file. Next time around, it will skip the search because the tag is known to exist. The problem with removing val-tags is that cvs will now search *always* before doing an update. Effectively, you will be condeming every end-user to an exhaustive search each time they do a cvs update -r RELENG_4 cd src/sys cvs up -r RELENG_4 ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 15560354 Mar 14 17:55 ktrace.out rm "RELENG_4" from val-tags on freefall ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 30356403 Mar 14 17:55 foo.out ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 15560711 Mar 14 17:55 foo2.out rm "RELENG_4" from val-tags on freefall ktrace cvs up -r RELENG_4 -rw------- 1 peter peter 30356761 Mar 14 17:56 foo3.out ie: if the RELENG_4 tag doesn't exist in val-tags, there is twice as much syscall activity, because the ncvs tree is scanned *twice* instead of once. The first is to see if RELENG_4 exists, the second entire scan is to update it. Note that my checked out tree is in sync already, no actual updates happened. You are looking solely at the ncvs/* scanning activity. If my memory serves correctly, the reason why the tag search is exhaustive rather than stops at the first match, is because it uses common scanning code for all consumers. Looking over your patch, it seems as though it skips the recursive scan. Is this correct? I could live with that, but if it going to do the recursive check each time, then no way :-). It looks like the worst case is that if you accidently do this: cd /usr/src; cvs up -r RELNG_4 then you'll end up with an empty tree, right? Again, if memory serves me correctly, the reason this was added in the first place was because if you had a 500MB checked out *remote* cvs tree, a simple typo on the "cvs up -r" line would cost a hell of a lot of network traffic to recover from. I know this has saved my backside at least twice with the gcc and bintuils anoncvs trees and once with mozilla. It takes forever to checkout and I'd hate to blow it away as a result of an typo. Secondly, why not export val-tags via cvsup? because if nobody has referenced a given tag on freefall, then each time the user does a 'cvs update' locally to that given tag, then cvsup will remove the cached "validated" local tag, and the end user will be forced to do an exhaustive scan again. As a footnote, you should have gone to MAINTAINER rather than arch first. If you add in a CVSROOT/config file check and make tag_check_valid() immediately return if the config file specifies it "off", then I'm happy. We could run with that on freefall. (assuming that it skips the recursion check and assumes that all tags are valid). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020315021550.B8F8F38CC>