Re: BUG: "cvs status" can do an update

[David Taylor]

Have recreated  this behavior in  CVS 1.11.1p1 on Solaris 7. Does not
happen in CVS 1.10.7 on Solaris 7.

dtaylor@ejasent.com

Eric Siegerman wrote:

> 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.        erics@telepres.com
> |  |  /
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea.
>         - RFC 1925 (quoting an unnamed source)
>
> _______________________________________________
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://mail.gnu.org/mailman/listinfo/info-cvs