[Top][All Lists]

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

Re: cvs update/checkout -f behavior

From: Bob Bowen
Subject: Re: cvs update/checkout -f behavior
Date: Wed, 23 Apr 2003 15:30:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

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?

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

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:

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


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

reply via email to

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