Re: cvs tag (mis)behavior

[Kaz Kylheku]

Derek Robert Price <derek@ximbiot.com> wrote in message 
news:<mailman.1822.1044995851.21513.bug-cvs@gnu.org>...
> Is there any good reason why 'cvs tag' will ignore files not currently 
> in the sandbox when -r is supplied?  It's supposed to operate locally, 

By ``locally'' I take it that you mean it pulls out the repository
location from your CVS/ administrative files, so no CVSROOT or module
argument needs to be supplied.

> but 'cvs update' is too and will find files that don't currently exist 
> in the sandbox when passed a tag via -r.
> 
> If nobody can argue successfully why this should be otherwise, I'm going 

It's impossible to argue successfully against changing the meaning of
something whose existing meaning is so useless that it can't be used.
Right now, if you use tag with -r, you are probably doing something
wrong.

> to alter the behavior of tag -r to match up -r.

This is great. It means that the tag command will do the right thing
in certain cases where otherwise rtag would have to be used. For
example, tagging a branch (that you are not updated to) before merging
it.

   cvs tag -r branch-x x-merge-25
   cvs update -j x-merge-24 -j x-merge-25
   cvs ci

This currently does not work; one is must use rtag. In the Meta-CVS
branching and merging code, I parse CVS/Root and CVS/Repository in
order to call rtag with the right repository location to match the
sandbox. It's a gross hack compared to just using a straightforward
sandbox-side operation.

Of course, since this is a recent fix, I have to continue to use the
rtag method, or else query cvs for its version and adjust the behavior
dynamically.