Re: PATCH: backport of symlink fix for issue 142 to cvs 1.11.9.1

[Paul Edwards]

"Mark D. Baushke" <mdb@cvshome.org> wrote in message 
news:mailman.2371.1066968374.21628.bug-cvs@gnu.org...
> Hi Folks,
>
> The following seems to be the minimum amount of change needed to
> implement a backport of the symlink bugfix that Derek put into
> the feature branch.

Wow!

> | Just wanted to note that this issue has been fixed, along with other
> | symlink related issues, on the feature branch since April.  I'm
> | leaving this issue open pending the completion of discussions with
> | Mark and Larry Jones on <bug-cvs@gnu.org>, but I think the needed
> | overhaul to fix all the symlink related issues is really too large to
> | be justifiable the stable branch and that symlink related fixes should
> | be considered the a new feature on the feature branch.
>
> Now that the patch is 'backported, it remains for folks to determine if
> it is too large to be justifiable in the stable branch.

Well.  CVS 1.11.7 introduced an immediately visible bug
that caused 1.11.8 to be created within 24 hours or something.

So "stable" is not infinitely stable already.  It is however
limited to bug fixes (or close).  It's not like this fix is designed
to support 50 different versions of network authorization that
weren't there before.  Sometimes bug fixes introduce bugs,
that's life, not just life, that's history already with 1.11.7.  So
long as it is for a good cause, and fixing a bug is a good cause,
problems should be tolerated.  So long as any subsequent bug
it introduces is either fixed, or the change backed out, that's
fine with me.

If there is an expectation that CVS works with repositories
that have symbolic links, and it doesn't currently actually
work, then it should be fixed.  You can issue a travel advisory
that it was a significant code change to implement the bug fix,
so that some people may defer adoption of it, but at least now
they have a version with the bug fix in.  Due care has been
taken to only implement what was required to fix it.

I see 1.11.x progressing for the next 5 years to end up having
the *current features*, with "no known bugs" not "no known
bugs except ones that required more than 200 lines of code
to fix".  For as long as there is someone willing to do the bug
fix, we should do it, danger and all.  The danger can be offset
by the end user by them waiting 2 months before implementing
each new stable release.  I don't think we want to be in a
position of turning down bug fixes because some impatient
person can't resist downloading the latest version.  Especially
since this is a freeware product.

Maybe we can get BUGS accurate and near-empty?

And it is difficult to tell what is dangerous anyway.  This
fix is probably less dangerous that the change in 1.11.7.
But we only know these things in hindsight.

So just do it!  :-)

> +    while ((pqdiff = tolower (*p) - tolower (*q)) == 0)

I think you need (unsigned char)*p

etc to conform to ISO/IEC 9899:1990.

BFN.  Paul.