Forwarding this to the list since I forgot CCing... sorry...
---------- Forwarded message ---------- From: Andrea Galbusera <[email protected]> Date: Fri, Jul 16, 2010 at 6:42 PM Subject: Re: cvs up and strange warnings for removed files To: Todd Denniston <[email protected]> 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 <[email protected]> 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:u...@localhost:/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:$u...@localhost:/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:giz...@localhost:/tmp/testcvs/repo/ co -d ./junkme-remote-trunk junkme cd junkme-remote-trunk/ touch file1 cvs -nq up ? file1 cd .. cvs -d:ext:giz...@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
