[EMAIL PROTECTED] on 2000.02.24 11:07:25
>Noel L Yap writes:
>>
>> System-wide preferences would have to exist on the same machine as the
binary.
>> So now, instead of "cvs diff" working differently from one directory to
another,
>> it would work differently depending on which server the repository resides.
It
>> would also mean that, if one were to move the repository, the behaviour of
>> commands would change.
>
>No, no, no, no, no. System-wide preferences would exist on the same
>machine as the *client* binary, not the server!
Ahhh, I see. This makes much more sense.
>As things currently
>stand, here's no reason I can see for a server to ever read a
>preferences file (i.e., the -f global option should be assumed for any
>server command, although the existing structure of the code may make
>that difficult, I haven't really looked to see).
This also makes sense (although I, too, haven't investigated how hard it would
be to do -- my guess, though, is that it's already there).
>> As for commands working differently from one directory to another. The
original
>> post regarded a per-repo CVSROOT/cvsrc file. I did mention possibly having
>> per-module .cvsrc files, but I don't consider it necessary and, I haven't
>> thought too much about it to deem it not dangerous.
>
>My point is that, for someone who works with multiple repositories,
>changing from one directory to another could change repositories and it
>would be very surprising for CVS commands to suddenly change their
>behavior just because of changing directories.
Yes, this is true. I'd say, though, that this feature shouldn't be used in
these environments, CVSROOT/cvsrc should be consistent among the various
repositories, or the user should override the repository default settings.
>You guys are once again trying to add warts to CVS to solve a problem
>that it was never intended to solve. If you have a bunch of users on a
>single machine, then having a machine-wide default preferences file (ala
>/etc/profile) would be a good solution.
If you have a bunch of users on the same machine, you might as well symlink or
copy the centralized /etc/cvsrc (or whereever it may be) to ~/.cvsrc. However,
this solution doesn't allow for fine-grained overriding or extending of
/etc/cvsrc.
>> If you have a bunch of users,
>>each with their own machine, then that wouldn't help much. Perhaps the
>>best solution to this problem would be to have "cvs" be a script that
>>checks for ~/.cvsrc and if it doesn't exist, copy a default one into
>>place for the user, then run the real cvs.
Yes, this is doable. Another solution might be to checkout CVSROOT/cvsrc onto
~/.cvsrc via "cvs co -p CVSROOT/cvsrc > ~/.cvsrc". Note that this also doesn't
allow for user overrides or extensions (in fact, it will even wipe out any such
user preferences).
>One more time: ~/.cvsrc contains *user* preferences that have nothing
>whatsoever to do with which repository the user is accessing (with the
>possible exception of cvs -z). They most definitely do *not* belong in
>the repository.
I think they should be allowed to belong in the repo if this is what the team
deems correct. "cvs -z" should definitely belong on the server since the server
is the one that can decide best what level of compression should be used.
