Hello, Noel!
> /etc/cvsrc is OK by me, but CVSROOT/cvsrc is more preferable. Some of the
> drawbacks with /etc/cvsrc are:
> 1. Defaults depend on which server the repo resides. If the repo is moved, the
> defaults may change.
> 2. /etc/cvsrc depends on sysadmin access. Some sites, including my own, don't
> have easy sysadmin access -- it'd be much easier to change something in the repo
> than something in /etc.
>
> Some of the benefits of CVSROOT/cvsrc are:
> 1. Each project may set their own defaults if they each have their own
> repositories.
> 2. None of the drawbacks mentioned above.
>
> Therefore, I won't fight against /etc/cvsrc (I just won't use it), but I will
> fight for CVSROOT/cvsrc.
>
> Now, I know the above list is biased, so I'd appreciate someone else giving some
> balance to those views.
CVSROOT/cvsrc is just much harder to implement properly. Suppose that you
set some options there. Then the client sends more options. How to decide
what to use?
Since some options cannot be negated (e.g. you cannot append something to
"update -d" that would cancel "-d") it's important to be able to cancel
global options alltogether.
The client should indicate somehow whether it wants per-site settings to
be honored. I don't see anything simpler than to introduce a global option
for this, e.g. "cvs -F" (or whatever you want)
Ideally, if we don't care about backward compatability, the "-F" flag
would be sent by clients that cannot read ~/.cvsrc
~/.cvsrc could still specify "cvs -F" explicitly to make CVS honor
CVSROOT/cvsrc as if ~/.cvsrc were missing.
However, the backward compatability can be a serious issue here.
Given the complexity of the problem and the number of conservators in this
list, I'm affraid that nobody will ever implement something like that.
Regards,
Pavel Roskin
