cvswrappers, .cvswrappers and client/server

[Peter Ring]

What is the current wisdom wrt. cvswrappers?

We are using cvs 1.11 (or 1.11p1) client/server (via ssh). I've a
.cvswrappers file to help make sure that the occasional binary file doesn't
get munged, like this:

  *.c
  *.cpp
  *.h
  ...
  *.xml

  # anything else is binary
  * -k 'b'

A previous version of cvs didn't really support the cvswrappers in the
repository over remote protocols, so I got into the habit of having a
~/.cvswrappers.

I believe that I've observed that I actually have to have the entries with
no options (like '*.c') in both the $CVSROOT/CVSROOT/cvswrappers and the
~/.cvswrappers if *.c should not get added -kb. I tried to digest the source
(wrapper.c), but must admit that I find it difficult to gather what exactly
the code is accomplishing.

Would I be better off with the more traditional list of known binary formats
in $CVSROOT/CVSROOT/cvswrappers and ~/.cvswrappers, like

  *.[Aa][Cc][Gg] -k 'b'
  *.[Aa][Cc][Ll] -k 'b'
  *.[Aa][Cc][Mm] -k 'b'
  *.[Aa][Cc][Ss] -k 'b'
  *.[Aa][Cc][Tt] -k 'b'
  ...
  *.[Xx][Ll][Tt] -k 'b'
  *.[Yy][Bb][Kk] -k 'b'
  *.[Zz][Ii][Pp] -k 'b'

Is the wrappers code designed to work in an 'additive' fashion so that the
entries with options could be in either the $CVSROOT/CVSROOT/cvswrappers or
the ~/.cvswrappers (or a local .cswrappers)? What takes precedence in case
the options are different?

Kind regards,
Peter Ring