> From: Derek Robert Price [mailto:[EMAIL PROTECTED] > Jim.Hyslop wrote: > > >Lars Huttar wrote: > > > >>Jim, > >>Thanks for your response. > >>The server version is > >> "Server: Concurrent Versions System (CVS) 1.11.2 (client/server)" > >>I'm inquiring as to what the server platform is (it's in another > >>state). > > > >A different state - possible a different time zone? If that's the > case, then > >Frederic Brehm's suggestion of a time difference _might_ be a > contributing > >factor, although CVS is usually fairly robust about clock differences > >between the client and server. > > > >What connection method do you use - pserver? ext? ssh? ...? > > > Move away, it is in the way really implies that CVS thinks that no > file should exist with that name in the sandbox at all. Which might > mean casing issues. There were a lot of casing bugs in old CVS > servers. You might try updating your CVS server to 1.11.15, if you > have the option. > > Derek
Well, it's not an easy option for us; the people who administer the server are considering moving to Subversion or something in a few months and are not inclined to invest much more time in CVS. (They also have much else on their plate.) But I will keep that in mind as an avenue to pursue. A new development in this problem is this: Background first: yesterday I removed all files again and checked out everything from scratch, using the cvs windows client, to make sure the cygwin client wasn't a factor in the problem. However behavior remained the same; subsequent cvs updates failed to update any existing files even when they had been newly committed to the CVS server from other machines. Same "in the way" messages. ** BUT: I discovered that there is one file that successfully gets updated on the test server: cocoon/sitemap.xmap In fact, cocoon/sitemap.xmap got updated from the CVS server even though it had been modified on the test server. (This is the desired behavior; I'm using -C.) The locally modified sitemap.xmap was moved to .#sitemap.xmap.1.2. No "in the way" message occurred for this file. Context: I'm running the "cvs update" command in the webapps folder, of which cocoon is a subfolder. The cocoon folder is the highest-level folder that has a "CVS" subfolder. My actual cvs client command is: ./cvs-win32.exe update -d -P -C (I renamed cvs.exe to cvs-win32.exe so I could be sure I wasn't using the cygwin cvs client.) So, I'm sure the fact that this sitemap.xmap file gets updated and the others don't must hold some clue to what the problem is. But I don't know how to interpret it. To further test along this avenue, I added a file as a sibling to sitemap.xmap, called test-foo.xml. I did this on another machine and committed the new file to the CVS server. The subsequent cvs update on the test server succeeded for this file; I got a "U cocoon/test-foo.xml" message and no "in the way" message. Then after making and commiting a change to this file from another machine, a cvs update on the test server again succeeded in updating test-foo.xml (which now already existed locally). So, maybe there's some difference between the cocoon folder, where files update successfully, and folders such as cocoon/mount/*, where updates don't work. Also, I observed that during cvs updates on the test server, the file cocoon/.cvsignore was generating an "in the way" message. (It had not been modified, either locally or on the cvs server.) So I tried making a commiting a change to .cvsignore on another machine, then running cvs update on the test server again. The result: an "it is in the way" error, a "C" (conflict), and the file was not updated on the test server. So, cocoon/sitemap.xmap and cocoon/test-foo.xml update successfully; cocoon/.cvsignore doesn't. Nor does anything under cocoon/WEB-INF or cocoon/mount/*, although I haven't tested a lot of different files under there individually. Any ideas on what may be happening?? Lars _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs