[Top][All Lists]

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

Re: cvs tag (mis)behavior

From: Kaz Kylheku
Subject: Re: cvs tag (mis)behavior
Date: 12 Feb 2003 16:37:22 -0800

Derek Robert Price <derek@ximbiot.com> wrote in message 
> 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

> 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

   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

reply via email to

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