[Top][All Lists]

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

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

From: Mark D. Baushke
Subject: Re: PATCH: backport of symlink fix for issue 142 to cvs
Date: Fri, 24 Oct 2003 00:07:46 -0700

Hash: SHA1

Hi Paul,

Paul Edwards <address@hidden> writes:

> "Mark D. Baushke" <address@hidden> wrote:
> > 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!

Well, Derek did most of the original work, my effort was just in
backporting it to cvs

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

Well, I ran into the problem with attempting to add LockDir to an
existing installation that happened to have moved their cvs repository
to a new machine and made the repository appear to be in the same place
as on the old machine by using a top-level symbolic link. It worked
fine... until they tried to use LockDir to point to a faster filesystem.
Moving forward to 1.12.1 makes them very nervous, so I needed to
make it work using a cvs 1.11.x release...

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

That is a very nice goal.

> 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!  :-)

Hmmm... I think I'll wait a bit and see if anyone else has anything to
say about it. :-)

> > +    while ((pqdiff = tolower (*p) - tolower (*q)) == 0)
> I think you need (unsigned char)*p
> etc to conform to ISO/IEC 9899:1990.

Good eyes. It seems that the feature branch has the same problem.

I'll make sure this gets into the tree after I've had a chance to
get some sleep. :-)

        -- Mark

Here is the revised cvs_casecmp to be used...

cvs_casecmp (str1, str2)
    const char *str1;
    const char *str2;
    const char *p;
    const char *q;
    int pqdiff;

    p = str1;
    q = str2;
    while ((pqdiff =
            tolower ((unsigned char)*p) - tolower ((unsigned char)*q)) == 0)
        if (*p == '\0')
            return 0;
    return pqdiff;
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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