cvs up and strange warnings for removed files

[Andrea Galbusera]

Hello CVS people,

I recently faced a strange behaviour, while using CVS update command.
Creating a file in my sandbox with the same name of a previously
removed file (I mean I file that some time in the past was in the
repository and then it was removed) and then running 'cvs -nq up',
ends up warning me with the following message:

cvs update: use 'cvs add' to create an entry for 'myfile'

Since I never noticed this before I decided to investigate and finally
found out that such a behaviour depends on the way I initially check
out my sandbox. Let me explain: checking out the source from a local
repository location draws to the warnings above, while checking out
from remote repository location gives no warning. Note that the
repository I check out from is the same: I simply change the method to
access it.

Here is the complete command sequence that makes the mismatching
behaviour reproducible. 'myfile' is a file that was previously removed
from repository.

Local checkout:
------------------------
$ cvs -d/cvsroot co -d ./sw-test-local -r mytag my/project
$ cd ./sw-test-local
$ touch myfile
$ cvs -n up
cvs update: use 'cvs add' to create an entry for 'myfile'

Remote checkout:
----------------------------
$ cvs -d:ext:***@localhost:/cvsroot co -d ./sw-test-remote -r mytag my/project
$ cd ./sw-test-remote
$ touch myfile
$ cvs -nq up
? myfile

I believe the 'remote' scenario is less confusing; this is also what I
was used to up to this morning, since I usually access the repository
from a different host.

Does anybody know the reasons behind this mismatch? Is there anything
I can do to avoid those confusing warnings. I have developers that
access the repository locally and others that connect remotely: since
I recently removed from cvs control some autotools artifacts that get
recreated inside sandbox at every build, this may lead to unnecessary
confusion for everybody.

TIA for any hint on this.

Regards,
Andrea

[Andrea Galbusera]

Arthur,

Thanks for replying and let me apologize for completely forgetting to
include this fundamental bits!

I'm running the test on Ubuntu Linux 8.04. The only CVS version
involved is 1.12.13 (client/server). I'm not using pserver but simply
accessing the repository either as a local directory or over ssh (both
test from the same host machine).

Does this shine some light?
Regards,
Andrea

On Thu, Jul 15, 2010 at 8:41 AM, Arthur Barrett

Andrea,

Post by Andrea Galbusera
I recently faced a strange behaviour, while using CVS update command.

Which version of CVS?  Eg: 1.12.1 server and 1.11.1 client (when using
ext)
Which operating system? Eg: Red hat Entperprise Linux 5u4 server, sun
solaris sparc 9 client
Regards,
Arthur

[Arthur Barrett]

Andrea,

Post by Andrea Galbusera
I recently faced a strange behaviour, while using CVS update command.

Which version of CVS? Eg: 1.12.1 server and 1.11.1 client (when using
ext)

Which operating system? Eg: Red hat Entperprise Linux 5u4 server, sun
solaris sparc 9 client

Regards,


Arthur

[Todd Denniston]

Post by Andrea Galbusera
Hello CVS people,
I recently faced a strange behaviour, while using CVS update command.
Creating a file in my sandbox with the same name of a previously
removed file (I mean I file that some time in the past was in the
repository and then it was removed) and then running 'cvs -nq up',
cvs update: use 'cvs add' to create an entry for 'myfile'
Since I never noticed this before I decided to investigate and finally
found out that such a behaviour depends on the way I initially check
out my sandbox. Let me explain: checking out the source from a local
repository location draws to the warnings above, while checking out
from remote repository location gives no warning. Note that the
repository I check out from is the same: I simply change the method to
access it.
Here is the complete command sequence that makes the mismatching
behaviour reproducible. 'myfile' is a file that was previously removed
from repository.
------------------------
$ cvs -d/cvsroot co -d ./sw-test-local -r mytag my/project
$ cd ./sw-test-local
$ touch myfile
$ cvs -n up
cvs update: use 'cvs add' to create an entry for 'myfile'

This is what I would expect you would need to do for a file name that in the past was in the
repository, but has been `cvs remove`ed. i.e. the same as for a file that has never existed.
However I could see it getting annoying to have that much verbiage coming out for every file that
has not yet been added to the repository... might have been a bad idea to make the change in this
behavior (between 1.11 & 1.12), or at least not make it optional.

Post by Andrea Galbusera
----------------------------
$ cd ./sw-test-remote
$ touch myfile
$ cvs -nq up
? myfile

I did not expect this to be different from above, but after thinking a little while...
the data in ./sw-test-remote/CVS/* will be for what exists in the current trunk/branch and not the
"DEAD" (i.e., removed) files, and apparently the client server protocol does not send the same
amount of information as the client has when it is operating directly on the repository directory
structure.

Post by Andrea Galbusera
I believe the 'remote' scenario is less confusing; this is also what I
was used to up to this morning, since I usually access the repository
from a different host.

To me the local is clearer, but they both mean the same thing... CVS _currently_ knows nothing about
./sw-test-local/myfile or ./sw-test-remote/myfile, and thus `cvs add myfile` needs done. The
difference is that in local mode cvs is aware that CVS _once_ was managing the file.

Post by Andrea Galbusera
Does anybody know the reasons behind this mismatch? Is there anything
I can do to avoid those confusing warnings. I have developers that
access the repository locally and others that connect remotely: since
I recently removed from cvs control some autotools artifacts that get
recreated inside sandbox at every build, this may lead to unnecessary
confusion for everybody.
TIA for any hint on this.
Regards,
Andrea

if you
cvs -d/cvsroot co -d ./sw-test-local -r mytag my/project
cd ./sw-test-local
touch myneverseenbeforename
cvs -n up

does myneverseenbeforename get the same "cvs update: use 'cvs add' ..." message?
If it does, then it is because in local mode for 1.12 someone has added that any unknown file should
get that message, but they did not do so for remote work... there should be some consistency.


I think this message is new in 1.12.X you are using, because I get different results:
mkdir -p /tmp/testcvs/repo/junkme
cd /tmp/testcvs/
cvs -d/tmp/testcvs/repo/ init
cvs -d /tmp/testcvs/repo/ version
###receive:
Concurrent Versions System (CVS) 1.11.22 (client/server)
####
cvs -d/tmp/testcvs/repo/ checkout junkme
cd junkme/
touch myfile
cvs add myfile
cvs commit -m"put the file in cvs" myfile
cvs remove -f myfile
cvs commit -m"remove the file from cvs" myfile
touch junkme
cvs -n update
###receive:
cvs update: Updating .
? junkme
####
cd /tmp/testcvs/
cvs -d/tmp/testcvs/repo/ checkout -d junkmelocal junkme
cd junkmelocal
touch junkme
cvs -n update
###receive:
cvs update: Updating .
? junkme
####
cd /tmp/testcvs/
export CVS_RSH=ssh
cvs -d:ext:$***@localhost:/tmp/testcvs/repo/ checkout -d junkmeremote junkme
cd junkmeremote/
touch junkme
cvs -n update
###receive:
? junkme
cvs update: Updating .
####

[Andrea Galbusera]

Forwarding this to the list since I forgot CCing... sorry...


---------- Forwarded message ----------
From: Andrea Galbusera <***@gmail.com>
Date: Fri, Jul 16, 2010 at 6:42 PM
Subject: Re: cvs up and strange warnings for removed files
To: Todd Denniston <***@tsb.cranrdte.navy.mil>


Hi Todd,
thank you for elaborating on this. See some more comments below.

Regards,
Andrea

On Thu, Jul 15, 2010 at 5:45 PM, Todd Denniston

Post by Todd Denniston

Post by Andrea Galbusera
------------------------
$ cvs -d/cvsroot co -d ./sw-test-local -r mytag my/project
$ cd ./sw-test-local
$ touch myfile
$ cvs -n up
cvs update: use 'cvs add' to create an entry for 'myfile'

This is what I would expect you would need to do for a file name that in the past was in the
repository, but has been `cvs remove`ed.  i.e. the same as for a file that has never existed.
However I could see it getting annoying to have that much verbiage coming out for every file that
has not yet been added to the repository... might have been a bad idea to make the change in this
behavior (between 1.11 & 1.12), or at least not make it optional.

A file that never existed before is marked with the question mark (?)
by 'cvs up' and you have three options for managing the situation.
First, you can ignore it and it will always be listed with the ? in
front of it: every such a file is listed before any other file known
to CVS. They may or may not annoy you, depending on how many they are.
Second option: you can decide that you want CVS to track revisions for
that file and proceed adding it with 'cvs add'. But you also have the
third chance: to ignore it by listing its name in your .cvsignore
file. It will never be listed anymore, unless you decide to add it
later to the repository.

The point is that the third option becomes uneffective if your file
has been 'cvs remove'ed before (in the local checkout scenario)! I
mean I will always see those annoying warning messages even if I add
the file to .cvsignore. I personally consider this not only annoying
but sometime confusing! I'll show you when this is the case by
example.

Post by Todd Denniston

Post by Andrea Galbusera
----------------------------
$ cd ./sw-test-remote
$ touch myfile
$ cvs -nq up
? myfile

I did not expect this to be different from above, but after thinking a little while...
the data in ./sw-test-remote/CVS/* will be for what exists in the current trunk/branch and not the
"DEAD" (i.e., removed) files, and apparently the client server protocol does not send the same
amount of information as the client has when it is operating directly on the repository directory
structure.

Post by Andrea Galbusera
I believe the 'remote' scenario is less confusing; this is also what I
was used to up to this morning, since I usually access the repository
from a different host.

To me the local is clearer, but they both mean the same thing... CVS _currently_ knows nothing about
./sw-test-local/myfile or ./sw-test-remote/myfile, and thus `cvs add myfile` needs done.  The
difference is that in local mode cvs is aware that CVS _once_ was managing the file.

Ok, I see your point, but consider what follows. You start managing a
set of sources with CVS because you need to quickly share the project
with other developers. You then realize that some of the files you
initially imported are better not to be version controlled, but they
still be present in your sandbox while developing: this is exactly the
case that brought me to write this post. I started developing my first
autotools-based project and decided that it was better to version
control 'Makefile.in's (even if they can be generated in pre-build
stage) to reduce the amount of dependencies for other developers (you
won't need autotools installed if you just want to configure and build
the project). I then realized this was not so good since this files
where changing too frequently and decided to remove them from CVS. But
they still always exist in any sandbox of that project, whenever a
build is run. Suppose a new developer join the development team _now_
and I give him access to the CVS repository: what it will see is a
bunch of messages about adding files that he never knew anything
about.

Post by Todd Denniston
if you
cvs -d/cvsroot co -d ./sw-test-local -r mytag my/project
cd ./sw-test-local
touch myneverseenbeforename
cvs -n up
does myneverseenbeforename get the same "cvs update: use 'cvs add' ..." message?

No, it get shown with ? in front of it

Post by Todd Denniston
If it does, then it is because in local mode for 1.12 someone has added that any unknown file should
get that message, but they did not do so for remote work... there should be some consistency.
mkdir -p /tmp/testcvs/repo/junkme
cd /tmp/testcvs/
cvs -d/tmp/testcvs/repo/ init
cvs -d /tmp/testcvs/repo/ version
Concurrent Versions System (CVS) 1.11.22 (client/server)
####
cvs -d/tmp/testcvs/repo/ checkout junkme
cd junkme/
touch myfile
cvs add myfile
cvs commit -m"put the file in cvs" myfile
cvs remove -f myfile
cvs commit -m"remove the file from cvs" myfile
touch junkme
cvs -n update
cvs update: Updating .
? junkme
####
cd /tmp/testcvs/
cvs -d/tmp/testcvs/repo/ checkout -d junkmelocal junkme
cd junkmelocal
touch junkme
cvs -n update
cvs update: Updating .
? junkme
####
cd /tmp/testcvs/
export CVS_RSH=ssh
cd junkmeremote/
touch junkme
cvs -n update
? junkme
cvs update: Updating .
####

I tryed your sequence with a clean repository and... ohoh! surprise! I
didn't see the annoying warnings... After a while of thinking I then
realized your testcase miss something wrt mine. I'm using branches!
So, let's set up another test, with a fresh repo and... I'm able to
reproduce it again! Looks like the trunk is behaving as I expect and
simply show ? when you re-touch a previously 'cvs remove'ed file. This
is not always the case for the branch: it sometimes show the warnings
and sometime not.

cvs -d /tmp/testcvs/repo init
mkdir junkme
cd junkme/
cvs -d /tmp/testcvs/repo/ import -m '' junkme ST START
cd ..
cvs -d /tmp/testcvs/repo co -d ./junkme-local junkme
cd junkme-local/
touch file1
touch file2
cvs add file1 file2
cvs commit -m '' file1 file2
**** now, let's create a branch ****
cvs tag -b branch
**** now let's remove file1 from trunk ****
cvs remove -f file1
cvs commit -m '' file1
**** let's create a "new" file1 and see what happens ****
touch file1
cvs -nq up
? file1
**** same behaviour in a locally checked out fresh copy of the trunk ****
**** let's see what happens on the branch ****
cvs up -r branch
cvs remove -f file1
cvs commit -m '' file1
cvs -nq up
cvs update: use `cvs add' to create an entry for `file1'
? file1

This is something new!!! We have both the regular new file report and
the warning suggesting to resurrect the old one.
Looks like CVS is making some confusion?

**** again, let's try also with a fresh checkout of the branch and see ****
cvs -d /tmp/testcvs/repo/ co -d ./junkme-local-branch junkme
cd junkme-local-branch/
touch file1
cvs -nq up
? file1

No warning!!!

**** last check is on remotely checked out copies of both trunk and branch ****
cvs -d:ext:***@localhost:/tmp/testcvs/repo/ co -d
./junkme-remote-trunk junkme
cd junkme-remote-trunk/
touch file1
cvs -nq up
? file1

cd ..
cvs -d:ext:***@localhost:/tmp/testcvs/repo/ co -d
./junkme-remote-branch -r branch junkme
cd junkme-remote-branch/
touch file1
cvs -nq up
? file1

Again: CVS behaviour looks more consistent on remotely checked out
copies. This is clear and confirms my first impression. But locally
checked out copies and branch_switched sandboxes behaves
differently... I'm getting lost. But a few more bits are coming to
light... branches seem to have an impact on this.

Could you please repeat the test above with the branch using your
version of CVS Todd?

Regards,
Andrea