[EMAIL PROTECTED] on 02/23/2000 05:46:40 PM
>> /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?
I think the order of use should be:
1. /etc/cvsrc
2. CVSROOT/cvsrc
3. ~/.cvsrc
One problem I see is how to decide whether something set in a later file should
override or extend the previous setting. There should be some way to specify
that in the files (perhaps with keywords such as "extends" and "overrides").
>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.
Yes, definitely.
>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)
This is one way, but it may not be optimal.
>Ideally, if we don't care about backward compatability, the "-F" flag
>would be sent by clients that cannot read ~/.cvsrc
I don't quite understand this. Clients should always be able to see ~/.cvsrc.
I guess backwards compatibility would break since the old servers won't
understand "-F". I'll have to think about this some more. In the end, if no
solution is found that doesn't break backwards compatibility, the issue should
be tabled.
>~/.cvsrc could still specify "cvs -F" explicitly to make CVS honor
>CVSROOT/cvsrc as if ~/.cvsrc were missing.
Oh, I was thinking it should be the other way around. Of course, if no
CVSROOT/cvsrc file existed, CVS shouldn't error.
>However, the backward compatability can be a serious issue here.
I agree.
>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.
Perhaps.
Noel
