bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checking a Tag


From: Mark D. Baushke
Subject: Re: Checking a Tag
Date: Wed, 23 Jul 2003 01:19:11 -0700

Roser Timm (KADA 31) <address@hidden> writes:

> As i never saw my request on the list i post it again - please excuse
> if you receive it twice.

This is the first time I have seen your report.
 
> We have a cvs problem that looks like a bug to me, and i'd like to
> hear your opinions:

Opinons are cheap and everyone can have one too, so let me see what I
think about your problem... :-)

> If we tag a module and later on delete the same tag on the module, cvs
> acts differently as when the tag has never been set.

Do you try to distinguish between 'the module' and 'all modules' here?

Just because you delete a tag from a few files in a module or even all
files in a particular module does not tell cvs that you have deleted all
possible occurances of that tag from the repository as a whole.

I would really rather that cvs not try to go thru some of my 30GB cvs
repositories to see if a given tag might be unused everywhere just
because I removed it from a few files. If I as an administrator know
that a particular tag was 'wrong' (say it violated a naming convention
or something), then I can always manually hack the val-tags file to
remove the entry there without having cvs grind thru all files in the
repository.

> I recon that cvs checks the val-tags file only when deciding whether
> the tag exists and doesn't look at the files themselves to say good or
> bad.

The cvs.texinfo file says this:

| @item cvs [checkout aborted]: no such tag @var{tag}
| This message means that @sc{cvs} isn't familiar with
| the tag @var{tag}.  Usually this means that you have
| mistyped a tag name; however there are (relatively
| obscure) cases in which @sc{cvs} will require you to
| @c Search sanity.sh for "no such tag" to see some of
| @c the relatively obscure cases.
| try a few other @sc{cvs} commands involving that tag,
| before you find one which will cause @sc{cvs} to update
| the @file{val-tags} file; see discussion of val-tags in
| @ref{File permissions}.  You only need to worry about
| this once for a given tag; when a tag is listed in
| @file{val-tags}, it stays there.  Note that using
| @samp{-f} to not require tag matches does not override
| this check; see @ref{Common options}.

There is presently no function in cvs to remove entries from the
val-tags file.

> This looks inconsistent to me: 
> if you check out a module with a tag, you would either expect cvs to 
>
>   - return with failure saying "no such tag" - when the tag has not
>     been set on the module
>
>   - or it should return the files in the tagged revision
>
> What it currently does is:
>
>   if the tag has been set once on any module in the Repository (and
>   therefore is in val-tags) it returns with success but with no files
>   when the tag has not been set (or deleted) on the module. 

Yes, this is the intended behavior at present.

>   It should return a failure and "no such tag" though !

You are free to remove the val-tags file or entries in it in those rare
cases where you have needed to purge the tag from all files.
 
> For any automated build process this is difficult to handle as the
> returncode of the checkout is not deterministic.

So, you want to file a bug to have us remove the val-tags processing
entirely and always just return zero files when you mistype a tag name?

This feature is really only there to quickly tell a user that the tag he
is attempting to use has not been seen via normal cvs operations
previously.

Feel free to have the taginfo trigger modify the val-tags file if it has
verified that all possible instances of a given tag have been removed.

If you or someone else feel sufficiently strong about it to introduce a
new command to control the val-tags file contents, feel free to discuss
its possible implementation on this list.

> Regards 
> 
> Timm

        Enjoy!
        -- Mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]