BUG: "cvs status" can do an update

[Eric Siegerman]

This bug exists in CVS 1.11.1p1; it was tested on Solaris 7, but
is probably system-independent.

Under certain specific circumstances, "cvs status" does an
"update".  The circumstances are:
  - a file foo exists in the repo, but not in the sandbox
  - I put a copy of foo into the sandbox (via cp, or any other
    means external to CVS)
  - The copy I parachute in is identical to the HEAD revision
    (i.e. no conflict as far as the *content* is concerned, but
    only as far as how the file came to exist)
  - I type "cvs status foo"
  - This command correctly says "Status: Needs Checkout",
    BUT THEN BRINGS THE FILE UP TO DATE.

Why this is a problem:  I always thought "cvs status" was a
read-only command, like "cvs diff" or "cvs log".  It is counter
to expectation that a command whose purpose is to display status
info ever change anything.  (The manual doesn't specify, as it
does for most other commands, but if it did, I'd expect it to
say:
    Changes: nothing
as do the sections on the other commands mentioned.)

N.B:
  - A no-arg "cvs status" won't do this
  - "cvs -n status foo" won't do it either (if it did I'd be
    *really* upset :-)
  - If the file I parachute in is NOT identical to the HEAD
    revision, "cvs status foo" behaves correctly:  it reports the
    conflict, and does NOT change anything.

Here's how to reproduce it.  Most of this is boring, and can be
quickly skimmed.  I've indicated the interesting parts with "###"
comments.

#
# Initial setup -- test directory with a test repo in it.
# ./out is the script log file; ignore it.
# Ignore Repos/foo as well; it's from another test and
# doesn't enter into this.
#
login1 8$ ls
Repos/  out
login1 9$ ls Repos
CVSROOT/  foo/
#
# Make a new project, and check it out into two sandboxes,
# "bar" and "bar2"
#
login1 10$ mkdir Repos/bar
login1 11$ cvs -d `pwd`/Repos co bar
cvs checkout: Updating bar
login1 13$ cvs -d `pwd`/Repos co -d bar2 bar
cvs checkout: Updating bar2
#
# Create a file via the "bar" sandbox
#
login1 14$ cd bar
login1 15$ echo test >foo
login1 16$ cvs add foo
cvs add: scheduling file `foo' for addition
cvs add: use 'cvs commit' to add this file permanently
login1 18$ cvs ci -m added
cvs commit: Examining .
RCS file: /home/microland/erics/t/Repos/bar/foo,v
done
Checking in foo;
/home/microland/erics/t/Repos/bar/foo,v  <--  foo
initial revision: 1.1
done

#
# Go to the "bar2" sandbox.  Poke and prod.
# All is as expected; nothing interesting happens.
#
login1 19$ cd ../bar2
login1 20$ cvs -nq up
U foo
login1 21$ cvs stat
cvs status: Examining .
login1 22$ ls
CVS/
login1 23$ cvs stat foo
===================================================================
File: no file foo               Status: Needs Checkout

   Working revision:    No entry for foo
   Repository revision: 1.1     /home/microland/erics/t/Repos/bar/foo,v

login1 24$ ls
CVS/
###
### Now do something nasty; parachute in "foo" from outside the sandbox,
### without telling CVS about it.
###
login1 26$ cp ../bar/foo .
login1 27$ ls
CVS/  foo
#
# Poke and prod some more.  Still nothing "interesting"...
#
login1 28$ cvs -nq up
U foo
login1 29$ cvs -nq up
U foo
login1 30$ cvs -nq up
U foo
login1 31$ cvs -nq up foo
U foo
login1 32$ cvs -nq up foo
U foo
login1 33$ cvs -nq up
U foo
login1 34$ ls
CVS/  foo
login1 35$ cvs stat
cvs status: Examining .
login1 36$ ls
CVS/  foo
login1 37$ cvs -nq up
U foo
###
### ... until now.  The next command brings "foo" up to date CVS-wise!
###
login1 38$ cvs stat foo
===================================================================
File: foo               Status: Needs Checkout

   Working revision:    No entry for foo
   Repository revision: 1.1     /home/microland/erics/t/Repos/bar/foo,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

###
### ... as the following demonstrates
###
login1 39$ ls
CVS/  foo
login1 40$ cvs -nq up
login1 41$ cat CVS/Entries
/foo/1.1/Wed Aug  8 20:22:36 2001//
D
login1 42$ 

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)