Re: cvs update/checkout -f behavior

[Bob Bowen]

Remi Gurski wrote:
> (The -f option for "cvs update" and "cvs checkout" forces a head 
> revision if tag/date is not found.)
>
> When issuing "cvs update -f -rtag" in a directory, it does as expected - 
> all files containing "tag" are checked out with that tag, as well as the 
> most recent version of all files not containing that tag. Unfortunately, 
> it still applies the sticky tag to these other files, so the next "cvs 
> update" removes them. "cvs update -f" will preserve them, but you have 
> to specify that option every time - and adding it to .cvsrc isn't really 
> an option, as you normally want the non-f behavior.
>
> It seems this is always undesired behavior - if I used the -f option 
> once, I want the untagged files to persist (presumably, continuing to 
> update with the latest version), i.e. set the sticky flags for files 
> containing the tag, and not for others. A "cvs update -rtag" command 
> undoes that later, if required.
>
> I consider this a bug. What does everyone else think? Is anyone else 
> using the -f option where the current behavior is desirable?
>
> Thanks,
> - Remi

I also consider it a bug and I know I'm not the only one.
Here's an exchange from last year:

Bob Bowen wrote:
> Eric Siegerman wrote:
> > On Mon, Feb 25, 2002 at 06:54:17PM +0000, Chuck Taylor wrote:
>
> > > I discovered last week that if I run
> > >
> > >     cvs update -f -r <branch_tag>
> > >
> > > in a working directory, then files that don't have <branch_tag>
> > > defined are checked out from the main trunk, as the -f option directs.
> > > However, CVS still applies the <branch_tag> sticky tag to these files,
> > > so subsequent cvs status commands result in errors on files that don't
> > > have the tag:
> > >
> > >     cvs status: <file> is no longer in the repository
> > >     ...
> > >     File:  <file>    Status: Entry Invalid
>
> > IMO that's a bug.  CVS shouldn't be able to put its own data
> > structures into a state that it considers invalid.
> >
> > That said, why are you only tagging some of the files?  Just tag
> > everything; then it won't be a problem.
> >
> > And using -f to override that, though of course
> > it shouldn't put CVS's data structures into an invalid state,
> > also shouldn't be expected to make up for the initial "garbage in".
>
>
> Then what is the purpose of the -f option? I've also run into this situation and
> as best as I can tell, using -f never gives you a viable result. You do get the
> desired versions, but as far as CVS is concerned, the workarea is unusable. Few
> cvs commands will work.
>
> Does anyone know why -f works this way?
>  
> =Bob=

I don't believe anyone responded to my question, but I think there have been 
a few other posts on this subject and the general advice seems to be to 
simply avoid using it as it's seldom useful.

Here is a link to one other message I just found that not only reports the 
issue but has a suggested fix:

   http://www.geocrawler.com/archives/3/383/1996/11/0/2114293/

I doubt this is still valid, but perhaps it suggests to the CVS maintainers 
a way to deal with the issue.

=Bob=

Bob Bowen   address@hidden   Process Engineering   (952)876-4635