[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Solution: cvs update: move away xyz; it is in the way (possible bug)

From: Chad Loder
Subject: Solution: cvs update: move away xyz; it is in the way (possible bug)
Date: Sun, 22 Apr 2001 16:15:03 -0800

I have done some more diagnostics with CVS and this mysterious
"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  projectABC/ projectXYZ/ CVS/

$ more CVS/Entries
/ Mar 21 16:00:00 2001//

  (notice that we are missing a directory entry for projectABC)

$ ls projectABC/ 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/; 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 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

Info-cvs mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]