Re: cvs tag (mis)behavior

[Mark D. Baushke]

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

> The case I am worried about is 'cvs tag -r release_1-0 -b
> maint_branch'. Why should that command behave differently in a sandbox
> checked out from project than 'cvs rtag -r release_1-0 -b maint_branch
> project', when a 'cvs up -r release_1-0' would generate the initial
> set of files rtag tagged as the base of the branch and the set of
> files tagged by the first (tag) command could be missing some files:
> 
>     cvs co -l .
>     mkdir project
>     cvs add project
>     cd project
>     touch file1 file2
>     cvs add file1 file2
>     cvs ci -maddem
>     cvs tag release_1-0
>     cvs rm -f file2
>     cvs ci -mbyebye
>     cvs tag -rrelease_1-0 -b release_1-0_maint
> 
> 
> will only tag file1.  Please name even a single case where that is
> useful.  Note that replacing the last tag command above with 'cvs up
> -rrelease_1-0' would pull down file1 and file2.

Ahhh... Yes, the example illustrates the problem more clearly. 
You make a good point.

The only situations I can come up with that the user might only want to
tag the subset of files in the current tree that intersect with a tag
are fairly contrived examples such as tagging the subset of all of the
files that have been modified in the last month that were part of the
original release_1-0 sources so that they could be sent to a third party
that is keeping the API files and libraries... That kind of behavior is
not really necessary. 

Another situation might be something like this:

     cvs checkout project/file1 project/file7 project/file9
     cd project
     cvs tag -rrelease_1-0 -b release_1-0_subset

where the user does not want to have to keep specifying the list of
files that are part of the subset, but it is also very contrived as
the user could as easily have checked out the release_1-0 files and
branched them without using the -rtag switch.

        -- Mark