RE: Checking a Tag

[Roser Timm (KADA 31)]

Derek Robert Price <derek@ximbiot.com> writes:

>>>Since the root of Timm's complaint was the non-deterministic return
>>>code from checkout, does it make sense to return an error code and
>>>print the no-such tag message when no files were checked out, only
>>>when a tag was specified?
>>>
>>>Just a thought.  I don't plan on doing the work myself just now.  I'll
>>>need to see a patch before I consider this seriously.
>>>    
>>>
>>
>>Hmmm... I suppose that could be an approach. I would worry that a makefile
>>that does a 'cvs update -r foo -dP subdirectory' where no files were found
>>because subdirectory was intended to be pruned could be a problem case...
>>  
>>
>
>I think it would be better for CVS to provide a consistent return code.  
>A user could always use `cvs up -dPrfoo subdirectory || true' or even 
>parse the actual output of the command for the "no such tag" error 
>message if they knew they'd like to ignore it.

Thats exactly what we are doing.

We have a repository with somewhat 250 modules (and ~ 1 million of files)
The piece of software as a whole consists of 80% of the modules upon which a 
release tag is drawn.
Now, if a developer wants to check out the lot, we have a set of ant tools that 
checkout the modules according to
a dependency list. Actually the list is rather long and no one can guarantee 
that all modules that are in the list
are really tagged with the same release tag. So prior to checking out 110 
modules and then find out that module no. 111 
doesn't exist with that tag, we implemented a check. 
The check validates the existance of the tag on all modules before starting to 
check out.  

Unfortunately it's of no use because when verifying the cvs return code it 
tells us: yeah guys ! your tag is there. 
It's only when having it checked out that we realize that nothing really got 
checked out.
Rdiff shows the same inconsistency as co does, so it's of no help either in 
this scenario.

And from Marks reply: 


>> 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?

Nope. The contrary would be what i'd be looking at - have an EXIT_FAILURE when 
your tag ain't there (mistyped or deleted) 
even though it's in the val-tags list.
What i was thinking of, is to have this return code when cvs checks out (or 
rdiffs) the module and 
finds out in the end that no files were send across the wire. To check it 
preliminary would be a big waste of time - 
this would somewhat erase the benefits of the val-tags file.
I recon this would have to be implemented as a counter or flag that increases 
or is set once a file is found with the provided tag.

Of course the better the return codes from cvs are, the better you can automate 
your buildprocess - so
as a developer i'd appreciate any effort in that direction. For the time being 
though it would be sufficient for us
to have it return EXIT_SUCCESS & EXIT_FAILURE correctly (or as we'd be 
expecting it if you want).

Thanks & Regards 
Timm