[Top][All Lists]

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

Proposed branch tag performance patch for feature

From: Kelly F. Hickel
Subject: Proposed branch tag performance patch for feature
Date: Wed, 3 Jan 2007 14:24:23 -0600

        I finally got around to completing this change, attached is a
unified diff (I attached it because the last patch was corrupted by
outlook) against cvs 1.11.21.
        This patch is only for the stable release, once it's been looked
over and approved, I'll do the feature release, I just didn't want to
get it all done and then find out the approach was flawed.
        I've included ChangeLog and sanity.sh changes, I believe the
sanity.sh tests are sufficiently paranoid, they did point out failures
with the previous patch.
        The previous patch improved my repo's branch time from 115
minutes to 8 minutes, this patch only gets it down to 12 minutes, but
since it's correct, I won't worry about the 4 "extra" minutes! ;>
        Let me know if there's anything that I missed, or if I can help
in any way to get this patch accepted.



Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc

> -----Original Message-----
> From: mdb@juniper.net [mailto:mdb@juniper.net] On Behalf Of Mark D.
> Baushke
> Sent: Wednesday, May 10, 2006 10:33 AM
> To: Kelly F. Hickel
> Cc: bug-cvs@nongnu.org
> Subject: Re: Proposed branch tag performance patch for feature and
> stable releases
> Hash: SHA1
> Hi Kelly,
> Point #1 of this has been communicated privately, but it occurs to me
> that the bug-cvs list may be interested in knowing what is happening.
> There are some problems with the proposed patch:
>   1) It is finding the the highest revision across all branches with
> the
>      right number of dots, not just the branches rooted at the same
>      revision. So, if you have a number of branches off 1.1 --
>, and, for example -- and then create a new branch
>      off of 1.2 you will get instead of as you should.
>      It is also checking all tags with the right number of dots, not
>      just magic branch tags.
>   2) For the FEATURE branch (1.12.x), there is an added problem in
> that
>      the file may be using a mixture of the CVS_LOCAL_BRANCH_NUM
> feature
>      along with regular branches. In this case, it is a good bet that
>      the user is using CVSup to make sure that revisions that are
> above
>      the CVS_LOCAL_BRANCH_NUM starting number will NOT be propagated
> to
>      mirrors of the repository and are thus not generally available.
>      So, if you have a number of global branches off 1.1 --,
>, as well as a few local branches and
>, then the next global branch created off of 1.1 will
>      incorrectly be set to instead of as expected.
>      Of course, this may not be that big a deal as in the normal
> course
>      of things new global branches are created on the master
> repository
>      and CVSup'd to the mirrors and the global will typically not have
> a
>      good reason to create a CVS_LOCAL_BRANCH_NUM, however, it has
>      happened that master repositories become dead and a new master is
>      elected from one of the mirrors which could lead to the above
>      problem.
>   3) The patch provided did pass our sanity.sh regression tests and
>      should not have. This means that we likely need to have a more
>      rigorous set of tests that the correct revisions are being
> created
>      by the cvs tag code. So, the proposed patch will probably also
> need
>      to include some sanity.sh tests to exercise it.
> Thank you for your consideration of this problem.
>       -- Mark
> Version: GnuPG v1.4.3 (FreeBSD)
> jtI9cRWSisG6ORRlK0CVQvE=
> =jvvC

Attachment: branch_performance_patch_1_11_21.txt
Description: branch_performance_patch_1_11_21.txt

reply via email to

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