Re: $Log$ substitution in binary files.

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Robert Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> > However, I'd suggest that in the case where the search back to find a \n
> > for <number-of-characters> does not find it, that cvs falls back to the
> > old-style RCS 'comment' character as the prefix to use by default.
> 
> 
> In addition to the 256 character limit?

The explicitly set RCS 'comment' character prefix would be allowed to be
of arbitrary length as is currently the case in RCS.

It is just that CVS would not bother looking further than
<number-of-characters> backward for a "\n" character.

> > In theory, a prefix of 1024 characters could be set if the user did a
> >
> >   cvs admin -c '<how-ever-many-characters-is-desired>' filename
> >
> > to explicitly set a prefix that exceeds your <number-of-characters>
> > heuristic limit...
> 
> 
> True.  I usually do dislike artificially imposed limits even when I
> can't think of a good reason why a comment leader larger than 20
> characters would be useful...  so a workaround would be nice...  Hrm...

Yup.

> Okay.  I can deal with that.  In fact, I tihnk I may drop the default
> limit to 20 characters, then, as a workaround is available for those
> who wish to use it.

Sure. Or you could make the heuristic number of characters a
CVSROOT/config option with a default value of 20. Folks that for some
reason need absurd limits could set it to -1 to have the same impact as
is currently in use, 0 to force use of the RCS comment character to
always be used or some positive value for how many characters need to
be examined before finding a \n characters and determining the prefix.

        -- Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBQc8H3x41pRYZE/gRAj5QAJ9wdLgRzO4JDqmlXjClTMF0zNAmbwCeO8x0
oXYs0Lbys3liiO34I+IsCCk=
=DGIm
-----END PGP SIGNATURE-----