Date: Wed, 13 Mar 2002 16:00:34 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Dag-Erling Smorgrav <des@ofug.org> Cc: obrien@FreeBSD.ORG, "Brian F. Feldman" <green@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Unmoronify CVS Message-ID: <3C8FE822.1B5FBC0B@mindspring.com> References: <xzphenkfaif.fsf@flood.ping.uio.no> <200203132158.g2DLwW611237@green.bikeshed.org> <20020313143522.A13768@dragon.nuxi.com> <xzpit8013n6.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > > "David O'Brien" <obrien@FreeBSD.ORG> writes: > > Neither of you two have yet to give real justification. > > I use -R all the time -- does that mean I am not using a "read-only" > > repo? I use serveral repos with "dozens or hundreds or thousands of > > modules" and it isn't "generally pisses [me] off". > > Because you don't use tags much, or the read-only repos you use have > fully populated val-tags. Yeah. How do you get a val-tags that's not fully populated, if your repository isn't writeable, so you can't lay down new tags, since if your repo was writable, you'd be able to write the tags file, too? > a) The tag you're asking for is in val-tags. No sweat. CVS scans all > the files you're asking it to operate on, and does whatever you > asked it to do. Yes. > b) The tag you're asking for exists, but isn't in val-tags. CVS will > scan all the files you're asking it to operate on, looking for the > tag - and it won't stop at the first hit. It will then add the tag > to val-tags (if possible) and go to a), or fail because val-tags > isn't writeable. Note that CVS processes every file twice - once > to see if it has the tag, and once to actually perform the > requested operation. I think that it should process every file, and stop at the first one that has the tag. Then it should add the tag to an internal list that it treats as if it were val-tags. Basically, this means that the writeability of the val-tags file should affect you. I would not mind if you added the printf: fprintf( stderr, "Hey moron, your val-tags is out of date!\n"); So that the repository maintainer can update the val-tags, since they are updating the rest of the world, but not the val-tags file for some reason unknown to mortal ken. ;^). In other words, I think that the two pass scan is necessary to the code knowing that a tag exists before it goes off and tries to do work in the context of a tag. Stopping the first pass after finding the tag, and starting the second in the context of the tag existing seems like the write thing. You could probably combine the pass based on the patches you posted. > c) The tag you're asking for does not exist. CVS will scan all the > files you're asking it to operate on, and give you an error message. > > Without val-tags, these three cases become: > > a) No difference. Yes. > b) Go directly to a), scanning each file once rather than twice, and > don't fail if the repo is read-only. > > c) Try to do whatever you asked it to do, and fail. I think that these might be slightly different behaviours, based on attempting to start the operation. In particular, there's a bad interaction with "-P" if you typo on a tag name that doesn't happen with the pre-validation of the tag, which your patch breaks. > So val-tags adds no value whatsoever in cases a) and b), and actually > pessimizes case b) (which I encounter often enough to be *really* > pissed off at val-tags). It all hinges on case c), so let's take a > closer look at it. My version of case b is much more often a typo on my part, than the intentional use of a non-existant tag. > The idea with case c) is that CVS should be able to tell you that none > of the files you asked it to operate on have the tag you specified. OR that the tag doesn't exist! > But: > > - That may be intentional. Maybe you're 'cvs up'ing to a nonexistent > tag in order to quickly and cleanly remove all unmodified files in > your tree. It's tempting to make a special tag like "HEAD" called "EMPTY" that could take care of this. > - You'd find out quickly enough anyway, at very little or no expense; > if you typed 'cvs up -rRELEN_4' by mistake, you'll very quickly > realize you've done something wrong, as CVS starts removing all > unmodified files, and you can recover by aborting and restarting > the command with the correct tag; you won't have lost anything. I think you might be screwed on sticky tags, in this instance. Also, the removing isn't inexpensive, and neither is getting it back. Using CVS over ssh over a slow link could make the removal very fast, and the recovery incredibly slow. > - When operating on portions of the tree, val-tags can give false > positives because the tag you asked for exists in another part of > the tree. This is true for tags that aren't over the entire tree. I'm of two minds on it. The first is that tags are tree-wide, and if the source in question is untagged, then the untagging is intentional, and not accidental. The second is that you might tag subtrees without using modules, even though this is contrary to the CVS documentation and FAQ, you could have discovered that it works. 8-). I think the "EMPTY" tag covers the first case. The second case almost wants to make the "case b" pass over the tree, if the pass is over a subtree that is not rooted at a module base (e.g. if I cd into /usr/src/sys/ufs and do it, vs. /usr/src/sys) ...but it assumes that val-tags tags are differentiable on a per module basis, which is wrong (for now), I think. > To summarize, val-tags saves a little time in a small number of cases, > is useless in most cases, and outright harmful in many common cases. It saves your butt in the slow-link-typo case... I think the cases where it's harmful are contrived: they are based on having bogus contents in the val-tags file in the first place. > And all this is a waste of my time; rather than ask why I want it > removed, you should accept that I (and many others) consider it an > incredible nuisance, and focus instead on explaining how *you* benefit > from it, so we can understand why you're opposed to my patch. I have to say that val-tags has saved my ass when using anonymous CVS to a read-only repository (NetBSD) over a 28k modem. I can see there being room for a patch that: 1) Caches the results of the val-tags update, so that if the update fails, the second pass doesn't fail. 2) Stops the first pass at the first file where the tag is seen, and converts immediately to second-pass. It probably needs to start from scratch in the "-P" case. This fixes your "case b" completely. I don't know if I agree with your "case c", but I can see some merit to it; a special tag (e.g. "EMPTY") on the order of "HEAD" would probably be the correct overall fix for this. If you wanted to cheap out, you could predicate the change on "-R present and -P absent", and only change to the patched behaviour in that case. Most people would find this much less objectionable. Though it still would bite you in the cases where val-tags has saved me, so I would prefer it if the behaviour is not changed using the "cheap out" approach. -- Terry 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?3C8FE822.1B5FBC0B>