RE: strange "it is in the way" message

[Lars Huttar]

> From: Derek Robert Price [mailto:address@hidden
> 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