I read this in the 1.10.8 NEWS file:

  * The -d command line option no longer updates the CVS/Root file.  For
  one thing, the CVS 1.9/1.10 behavior never had updated CVS/Root in
  subdirectories, and for another, it didn't seem that popular in
  general.  So this change restores the CVS 1.8 behavior (which is also
  the CVS 1.9/1.10 behavior if the environment variable
  CVS_IGNORE_REMOTE_ROOT is set; with this change,
  CVS_IGNORE_REMOTE_ROOT no longer has any effect).

I'm not sure I understand quite what's going on here.  We're currently
running 1.10; I'm looking to move us up to 1.10.8 sometime, and am doing
some preparatory research.  I'm concerned (probably unduly) that
something here will cause normal practices around here to break.

We use the -d command line option a lot because there are several CVS
roots in house.  For example, if I'm working on projectX, I might have a
working directory structure like this:

/home/lnelson/projects/projectX

...where projects is just a "normal" directory.  I cd into projects and
do cvs checkouts like this:

% cd $HOME/projects
% cvs -d:pserver:[EMAIL PROTECTED]:/the/projectX/cvsroot checkout
projectX

...then sit back while cvs churns.  From that point forward I can go
into projectX and do updates and so forth without using the -d option. 
I assume I can still do this, yes?

(Am I to understand that 1.10's behavior was something like this: if I'm
in my projectX working directory and someone moves the CVS root on the
server out from under me I can do a cvs -d<new location of cvsroot> in
my working directory and the intent was to have cvs update my project's
Root files so that the new cvs root is found?  If that's what's going
on, that's cool; we never made use of this feature anyhow.)

Cheers,
Laird

Reply via email to