Hi Ingo! Thank you very, very much for your valuable, in-depth answer and advice! I have issues with the system loosing it's routes. Because of this I had tried several mirror sites and must have caught the divergent entries doing so. Your advice solved the problem. Thanks again! Cheers,STEFAN Gesendet: Dienstag, 14. Oktober 2014 um 15:24 Uhr Von: "Ingo Schwarze" <schwa...@usta.de> An: "Stefan Wollny" <stefan.wol...@web.de> Cc: openbsd-misc <misc@openbsd.org> Betreff: Re: cvs update: move away <any file>; it is in the wayHi Stefan,
Stefan Wollny wrote on Tue, Oct 14, 2014 at 02:25:04PM +0200: > I am puzzled with a strange behaviour of CVS. > > In my .profile I have > PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ > CVSROOT=anon...@ftp.hostserver.de:/cvs > export PKG_PATH CVSROOT When updating a tree, there are two places where cvs(1) looks for the CVSROOT that applies to each directory: (1) In the CVS/Root file of the directory, if any and (2) in the CVSROOT environment variable or the cvs -d command line option. If (1) and (2) mismatch, you get conflicts for all affected files. Note that your .profile shown above may or may not have influenced what was put into some CVS/Root files in the past and may or may not have influenced your current CVSROOT setting in the environment: .profile is somewhat unrelated to your problem. > Now when updating e.g. /usr/src I get the following: > > /usr/src $ sudo cvs -q up -Pd > cvs update: move away bin/ln/Makefile; it is in the way > C bin/ln/Makefile > cvs update: move away bin/ln/ln.1; it is in the way > C bin/ln/ln.1 > cvs update: move away bin/ln/ln.c; it is in the way > C bin/ln/ln.c > cvs update: move away bin/ln/symlink.7; it is in the way > C bin/ln/symlink.7 > > This goes on like this for any file in /usr/src. > > Is this expected behaviour??? I doubt it ... It really depends on what your are actually doing. Your first step should be to figure out the state of your tree: $ find /usr/src -path \*/CVS/Root -print -exec cat {} \; Do not post the result because it is likely very long. If all those files have identical content, you can fix your problem by simply running against that server again (set CVSROOT in your *current* environment - not .profile - or run cvs with -d). If those files have *different* content, you need to figure out whether you did that on purpose or accidentally. If you did that on purpose and have a CVS/Root file in each directory, simply using these files by unsetting the CVSROOT environment variable may be enough - but note that will update different parts of the tree against different servers. I doubt you did it on purpose or you wouldn't be asking this question. If you did *not* do this on purpose, removing the CVS/Root files is likely to solve your problem: $ find /usr/src -path \*/CVS/Root -print -exec rm {} \; Obviously, do *NOT* do that in a tree where you intentionally mixed content from different servers, or where you might forget which servers parts of it came from. Also, note that short of manually recreating CVS/Root files in all directories, you will never again be able to use a tree where you did that without having CVSROOT set or specifying cvs -d. After running the removal, simply set CVSROOT to the server you want and cvs up -dP away. Note that some CVS/Root files will reappear in the future, but only in newly created directories. > Beside deleting the sources and GETing a fresh checkout? In case you are unsure about the state of your tree, for example if you think you ran various commands of unknown effect without knowing what you were doing, and in case it is important that the tree be reliable, for example because you want to build releases from it that you want to run in production, that might be advisable. In case you are sure that the only bad thing you did was running cvs up against varying (as opposed to untrusted!) servers and nothing except CVS/Root files is corrupt, that is not needed. It is your call to decide whether you still trust your tree. Only you know what you did to it, or if you do not, well, that's a data point, too... Yours, Ingo
