Date: 15 Mar 2002 03:29:35 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <xzp1yemtvg0.fsf@flood.ping.uio.no> In-Reply-To: <20020315021550.B8F8F38CC@overcee.wemm.org> References: <20020315021550.B8F8F38CC@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm <peter@wemm.org> writes: > 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). Yep, even if it finds the tag in the very first file. > 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 No - my patch disables the entire tag-checking code. > 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. Correct. > 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? Any sensible person would discover his mistake and abort the update long before that, and cvs does not remove modified files, so no real harm is done. DES -- Dag-Erling Smorgrav - des@ofug.org 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?xzp1yemtvg0.fsf>