On Wed, 11 Feb 2004, Lubos Vrbka wrote:

> Frederick Bruckman wrote:
>
> > "Setting the variable manually" means using "-d". "cvs" follows the
> > usual unix convention of "command line options override config file
> > settings; config files setting override environment variables".
> well, i've just looked again in man for cvs:
>
>   -d CVS_root_directory
>                Use  CVS_root_directory  as  the  root directory pathname of the
>                master source repository.  Overrides the setting of the  CVSROOT
>                environment  variable.   This  value  should  be specified as an
>                absolute pathname.
> CVS/Root
>                Pathname to the repository ( CVSROOT ) location at the  time  of
>                checkout.   This file is used instead of the CVSROOT environment
>                variable if the environment variable is not set.  A warning mes-
>                sage  will be issued when the contents of this file and the CVS-
>                ROOT environment variable differ.  The file may  be  over-ridden
>                by  the presence of the CVS_IGNORE_REMOTE_ROOT environment vari-
>                able.
>
> according to this: if i export CVSROOT it should be always used instead of the
> contents of CVS/Root.

If that were true (and it doesn't seem to be), that would be decidedly
non-intuitive. A careful reading reveals that it doesn't actually
specify which dominates if the environment variable *is* set, though,
as I said, the normal unix convention would be to go with the file.

> if i specify -d, both CVSROOT and CVS/Root are overriden.

Correct.

> as i exported CVSROOT it should have been used, but it wasn't => cvs does not
> behave as it should here for the first case (i haven't tested -d switch)... also
> the effect CVS_IGNORE_REMOTE_ROOT variable isn't clear to me...

I think it means the "CVS/Root" files are ignored, except for,
perhaps, the top-level one. It helps to know that that environment
variable was added at the same time the feature was added, to permit
each subdirectory to be fetched from a different server. So, I expect
it to simply restore the old, default behaviour, of getting all
subdirectories from the same server, though I haven't tried it.

> > I guess it means that "distinfo" is present, but not correctly
> > recorded in "CVS/Entries" for whatever reason. You could just delete
> > it, and try a "cvs update" again (from within that directory).
> do you mean deleting CVS/Entries, or the offending files? the message is
> displayed not only for some distinfos, but also for some PLISTs, DESCRs,
> patches, Makefiles, licenses...

I mean the offending file. These may all be consequences of your
interrupted updates. What I would do, is log the next update:

   cvs -z3 update > /var/tmp/pkgsrc.cvs.log

After that's done, all such files will be listed in the log with a
"?", so you can then get a list of files to delete with

  awk '/[?]/ {print $2}' /var/tmp/pkgsrc.cvs.log

(There are many other ways, of course.) Be careful! Any files or local
patches you've added will be listed there, too, so I would capture
that to a file and edit by hand before piping to "xargs rm". If you
keep getting such errors on subsequent (complete) updates, it probably
means your file system is trashed, so lets hope that doesn't happen.

Frederick