[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $Log$ substitution in binary files.

From: Mark D. Baushke
Subject: Re: $Log$ substitution in binary files.
Date: Fri, 10 Sep 2004 08:57:59 -0700

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...


> 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

Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]