Fwd: cvs up and strange warnings for removed files

[Andrea Galbusera]

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


---------- Forwarded message ----------
From: Andrea Galbusera <address@hidden>
Date: Fri, Jul 16, 2010 at 6:42 PM
Subject: Re: cvs up and strange warnings for removed files
To: Todd Denniston <address@hidden>


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
<address@hidden> wrote:
>>
>> 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'
>>
>
> 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.

>> Remote checkout:
>> ----------------------------
>> $ cvs -d:ext:address@hidden:/cvsroot co -d ./sw-test-remote -r mytag 
>> my/project
>> $ 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.
>
>
>> 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.

> 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

> 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:address@hidden:/tmp/testcvs/repo/ checkout -d junkmeremote junkme
> cd junkmeremote/
> touch junkme
> cvs -n update
> ###receive:
> ? 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:address@hidden:/tmp/testcvs/repo/ co -d
./junkme-remote-trunk junkme
cd junkme-remote-trunk/
touch file1
cvs -nq up
? file1

cd ..
cvs -d:ext:address@hidden:/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