cvs update: move away xyz; it is in the way
Chad Loder
my CVS sources:
cvs update: move away foo.c; it is in the way
where foo.c is a file that's still in the archive,
whose sandbox version is up-to-date w.r.t. the repository
version, and so on...I've never touched the thing.
I saw some posts in the mail archives about this sort
of thing, with some responses giving implausible
explanations. :)
What should I be looking at, if I really want to know
what's causing this and how to stop it.
Thanks,
Chad Loder
_______________________________________________
Info-cvs mailing list
Info...@gnu.org
http://mail.gnu.org/mailman/listinfo/info-cvs
Mike Castle
> Hello. I'm getting inexplicable messages when updating
> my CVS sources:
>
> cvs update: move away foo.c; it is in the way
>
> where foo.c is a file that's still in the archive,
> whose sandbox version is up-to-date w.r.t. the repository
> version, and so on...I've never touched the thing.
Is there still an entry for it in CVS/Entries?
Perhaps that file got corrupt somehow?
> I saw some posts in the mail archives about this sort
> of thing, with some responses giving implausible
> explanations. :)
I used to see it all the time on Win32 systems where people had two files
of the same name but mixed case. :-/
> What should I be looking at, if I really want to know
> what's causing this and how to stop it.
Move the file out of the way, do an update, and then verify that they
actually do have the same contents.
mrc
--
Mike Castle Life is like a clock: You can work constantly
dal...@ix.netcom.com and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
Larry Jones
>
> cvs update: move away foo.c; it is in the way
>
> where foo.c is a file that's still in the archive,
> whose sandbox version is up-to-date w.r.t. the repository
> version, and so on...I've never touched the thing.
That message indicates that CVS thinks the sandbox file didn't come from
the repository file but from somewhere else. Check CVS/Entries (and
CVS/Entries.Log if it exists) paying careful attention to case
differences or invisible control characters that may be confusing CVS.
If you're using client/server CVS, having one (either the client or the
server) that's case sensitive and one that's case insensitive can also
lead to these kinds of problems.
-Larry Jones
Santa's gonna skip this block for years. -- Calvin
Gary Heuston
in the developers staging area but didn't have anything in the Entries
file associated with it. This could be happening because a file was
copied manually into the area and then you tried to update it? In this
case I would suggest you get the file out using CVS so there is an
Entries associated with it then do the copy and update.
Chad Loder
This is not the case. Yesterday, I blew away my sandbox (including all
the CVS/ subdirectories) and did a fresh cvs update. Today, having not
touched any of the source files, I do an update and get the messages
I described.
Now, changes maybe HAVE been made to the repository by other
developers since yesterday's "clean" update, but not by me.
Would it be worth trying to correlate these possible repository
changes with what I'm seeing? I'd have to hunt down the logs on the
server...
c
At 02:44 PM 3/9/2001 -0600, you wrote:
>In our case this happened when we tried to check out a file that existed
>in the developers staging area but didn't have anything in the Entries
>file associated with it. This could be happening because a file was
>copied manually into the area and then you tried to update it? In this
>case I would suggest you get the file out using CVS so there is an
>Entries associated with it then do the copy and update.
>
>Gary
>gary.h...@afwa.af.mil
>
>Chad Loder wrote:
>
Gary Heuston
what the Entries file says and whats actually sitting in the directory. You
might want to manually examine your Entries file for that directory (or any
you are having a problem with) and see what the differences are...as Larry
said it could even be just a random extra character in there. Regular
changes to the repository shouldn't cause this (after all thats what update
is for!)
BTW when you blew your sandbox away, I assume you did a checkout before an
update? I'm pretty sure you can't do an update without having some entry in
the Entries file somewhere to actually update...otherwise it should give you
a "there is no version here" error...
Chad Loder wrote:
> Gary,
>
> This is not the case. Yesterday, I blew away my sandbox (including all
> the CVS/ subdirectories) and did a fresh cvs update. Today, having not
> touched any of the source files, I do an update and get the messages
> I described.
>
> Now, changes maybe HAVE been made to the repository by other
> developers since yesterday's "clean" update, but not by me.
>
> Would it be worth trying to correlate these possible repository
> changes with what I'm seeing? I'd have to hunt down the logs on the
> server...
>
Chad Loder
Let's take an example directory from my sandbox.
Here is the result of 'cvs update -dP':
cvs server: Updating shared/java/com/rapid7/net/http
cvs update: move away shared/java/com/rapid7/net/http/HTTPClient.java;
it is in the way
(yada yada yada, repeat message for each file in the directory)
I notice a disparity between the timestamps in the CVS/Entries file
for that directory, and the timestamps of the actual files as
reported by `ls -l`.
For example, `ls -l` reports:
-rw-r--r-- 1 chadlode None 726 Mar 5 11:02 Makefile.mk
whereas the CVS/Entries file contains:
/Makefile.mk/1.4/Mon Mar 5 19:02:18 2001//
That is, the CVS/Entries file says "7:02 pm", but the local filesystem
says "11:02 am" -- could this be the problem? I smell some bad timezone
math or something...
Here's the entire CVS/Entries file:
/HTTPClient.java/1.2/Fri Mar 2 14:01:39 2001//
/HTTPCookie.java/1.2/Fri Mar 2 14:01:39 2001//
/HTTPCookieDatabase.java/1.2/Fri Mar 2 14:01:39 2001//
/HTTPException.java/1.1/Tue Feb 27 14:05:37 2001//
/HTTPHeaders.java/1.2/Fri Mar 2 14:01:39 2001//
/HTTPInteractive.java/1.2/Fri Mar 2 14:01:40 2001//
/HTTPRequest.java/1.3/Fri Mar 2 14:01:40 2001//
/HTTPRequestTimings.java/1.2/Fri Mar 2 14:01:41 2001//
/HTTPResponse.java/1.2/Fri Mar 2 14:01:41 2001//
/HTTPSession.java/1.3/Fri Mar 2 14:01:41 2001//
/HTTPSession1945.java/1.2/Fri Mar 2 14:01:41 2001//
/HTTPSession2616.java/1.3/Fri Mar 2 14:01:42 2001//
/HTTPSessionFactory.java/1.3/Fri Mar 2 14:01:42 2001//
/HTTPSessionParams.java/1.2/Fri Mar 2 14:01:43 2001//
/HTTPUtils.java/1.2/Fri Mar 2 14:01:43 2001//
/Makefile.mk/1.4/Mon Mar 5 19:02:18 2001//
/Test_HTTPSessionFactory.java/1.2/Fri Mar 2 14:01:44 2001//
/URLEncoder.java/1.2/Fri Mar 2 14:01:44 2001//
D
...and here is an `ls -l` of the sandbox directory:
total 64
drwxr-xr-x 2 chadlode None 4096 Mar 8 05:54 CVS
-rw-r--r-- 1 chadlode None 2396 Mar 2 06:01 HTTPClient.java
-rw-r--r-- 1 chadlode None 10818 Mar 2 06:01 HTTPCookie.java
-rw-r--r-- 1 chadlode None 4009 Mar 2 06:01 HTTPCookieDatabase.java
-rw-r--r-- 1 chadlode None 1219 Feb 27 06:05 HTTPException.java
-rw-r--r-- 1 chadlode None 5488 Mar 2 06:01 HTTPHeaders.java
-rw-r--r-- 1 chadlode None 11845 Mar 2 06:01 HTTPInteractive.java
-rw-r--r-- 1 chadlode None 3862 Mar 2 06:01 HTTPRequest.java
-rw-r--r-- 1 chadlode None 4402 Mar 2 06:01 HTTPRequestTimings.java
-rw-r--r-- 1 chadlode None 2433 Mar 2 06:01 HTTPResponse.java
-rw-r--r-- 1 chadlode None 29301 Mar 2 06:01 HTTPSession.java
-rw-r--r-- 1 chadlode None 2137 Mar 2 06:01 HTTPSession1945.java
-rw-r--r-- 1 chadlode None 9019 Mar 2 06:01 HTTPSession2616.java
-rw-r--r-- 1 chadlode None 4805 Mar 2 06:01 HTTPSessionFactory.java
-rw-r--r-- 1 chadlode None 1116 Mar 2 06:01 HTTPSessionParams.java
-rw-r--r-- 1 chadlode None 14731 Mar 2 06:01 HTTPUtils.java
-rw-r--r-- 1 chadlode None 726 Mar 5 11:02 Makefile.mk
-rw-r--r-- 1 chadlode None 2396 Mar 2 06:01
Test_HTTPSessionFactory.java
-rw-r--r-- 1 chadlode None 7528 Mar 2 06:01 URLEncoder.java
At 03:38 PM 3/9/2001 -0500, you wrote:
>That message indicates that CVS thinks the sandbox file didn't come from
>the repository file but from somewhere else. Check CVS/Entries (and
>CVS/Entries.Log if it exists) paying careful attention to case
>differences or invisible control characters that may be confusing CVS.
>If you're using client/server CVS, having one (either the client or the
>server) that's case sensitive and one that's case insensitive can also
>lead to these kinds of problems.
_______________________________________________
Chad Loder
away.
c
At 04:00 PM 3/9/2001 -0600, you wrote:
>The reason this error is popping up is CVS is detecting a difference between
>what the Entries file says and whats actually sitting in the directory. You
>might want to manually examine your Entries file for that directory (or any
>you are having a problem with) and see what the differences are...as Larry
>said it could even be just a random extra character in there. Regular
>changes to the repository shouldn't cause this (after all thats what update
>is for!)
>
>BTW when you blew your sandbox away, I assume you did a checkout before an
>update? I'm pretty sure you can't do an update without having some entry in
>the Entries file somewhere to actually update...otherwise it should give you
>a "there is no version here" error...
>
>Gary
>gary.h...@afwa.af.mil
>
>Chad Loder wrote:
>
> > Gary,
> >
> > This is not the case. Yesterday, I blew away my sandbox (including all
> > the CVS/ subdirectories) and did a fresh cvs update. Today, having not
> > touched any of the source files, I do an update and get the messages
> > I described.
> >
> > Now, changes maybe HAVE been made to the repository by other
> > developers since yesterday's "clean" update, but not by me.
> >
> > Would it be worth trying to correlate these possible repository
> > changes with what I'm seeing? I'd have to hunt down the logs on the
> > server...
> >
>
>
Larry Jones
>
> I notice a disparity between the timestamps in the CVS/Entries file
> for that directory, and the timestamps of the actual files as
> reported by `ls -l`.
Unless you're in England, that's to be expected; CVS/Entries timestamps
are in UTC, ls generally reports timestamps in local time.
Your Entries file looks fine to me, so I'm completely mistified by your
problem at this point.
-Larry Jones
Just when I thought this junk was beginning to make sense. -- Calvin
Chad Loder
"move away XYZ; it is in the way" problem. I think I have found
my problem (and solution) -- I'm just not sure how things got
fubar'd in the first place.
The problem occurs when a subdirectory in the repository is not
listed in the CVS/Entries file of its parent directory.
This may occur when developers do not correctly (or completely)
add directories to the repository...I imagine the scenario goes
something like this:
Sometimes Developer X will make a mistake when checking in or
importing an entire subdirectory. Developer Z will call him and
the following conversation ensues:
Developer Z: Hey, you broke the build, did you forget to check in
the entire ABC directory?
Developer X: No, I checked it in alright...I don't know what YOUR
problem is.
Developer Z: Oh hmmm...let me create the directory manually on my
sandbox and then refresh...ahhh that worked. Weird.
Oh well, never mind.
The end result of this is that the manually-created directory's
parent directory has not been informed of this new subdirectory.
In other words, let's say we have the following setup:
$ cd /project
$ ls
Makefile.mk projectABC/ projectXYZ/ CVS/
$ more CVS/Entries
/Makefile.mk/1.0/Wed Mar 21 16:00:00 2001//
D/projectXYZ////
(notice that we are missing a directory entry for projectABC)
$ ls projectABC/
Makefile.mk Readme.txt CVS/
(now when we run CVS update -dP from the parent directory, we will
get errors in the projectABC/ directory)
$ cvs update -dP
cvs server: updating projectABC
cvs update: move away projectABC/Makefile.mk; it is in the way
Please NOTE that this error only occurs when one issues a "blanket"
update command to the server -- I assume this is because the server
returns a "blanket" response that includes files in directories which
are not mentioned in any Entries file.
So, IMHO, this problem is caused by user error but SERIOUSLY compounded
by a confusing error message in CVS. I have been thinking of how to
patch CVS to detect this situation...one minor complication would be
how to programatically differentiate between this situation and other
similar situations (e.g., where a subdirectory has been removed into the
attic, then a subdirectory by the same name has been re-added to the
project, containing some files with the same names). I think such a
patch would be possible.
Alternatively, we could do something to prevent such mis-use. I'm still
not sure of the exact sequence of commands that newbies use to create
this problem, it must be fairly easy to do because I've seen it
before. We could either prevent Developer X from messing up the
directory check-in in the first place, or prevent Developer Z from
"hacking" around the problem by manually adding the directory.
I'm open to suggestions.
Chad Loder
At 10:37 AM 3/12/2001 -0500, you wrote:
>Chad Loder writes:
> >
> > I notice a disparity between the timestamps in the CVS/Entries file
> > for that directory, and the timestamps of the actual files as
> > reported by `ls -l`.
>
>Unless you're in England, that's to be expected; CVS/Entries timestamps
>are in UTC, ls generally reports timestamps in local time.
>
>Your Entries file looks fine to me, so I'm completely mistified by your
>problem at this point.
>
>-Larry Jones
>
>Just when I thought this junk was beginning to make sense. -- Calvin
>