RE: Proposed branch tag performance patch for feature and stable releases

[Kelly F. Hickel]

Mark,
        I've been thinking about how to solve this, how does the
proposed pseudo-code below sound?  This seemed like a heavy approach
given the fact that it's creating and sorting a new list, but it seems
the best way to find the correct magic revision number in an efficient
way.  For low branch counts the list will be small enough that it should
still perform well compared to the current code.

findnextmagicrev:
1)  Determine number of dots (numdots) in the current revision
2)  Create a new list that will receive the integer values of the last
term of each tag that might conflict with the candidate.
3)  Walk the list of RCS_symbols:
    a) if the rev has numdots+1 AND the final term is even, insert the
integer value of the final term into the list.
    b) if the rev has numdots+2 AND the final term is an even number,
AND the term before the final term matches RCS_MAGIC_BRANCH, insert the
integer value of the final term into the list.
4)  Call sortlist on the list, sorting it into ascending order of
integer values.
5)  go through the list, find the first gap, that's the new magic
revision number.


Then I'll have to figure out enough of sanity.sh to add a test case for
the old code, make sure the released codes passes, and that my previous
patch fails, and that the new patch passes.

-- 

Kelly F. Hickel
Senior Software Architect
MQSoftware, Inc
952.345.8677
kfh@mqsoftware.com


> -----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
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 --
> 1.1.0.2,
>      1.1.0.4, and 1.1.0.6, for example -- and then create a new branch
>      off of 1.2 you will get 1.2.0.8 instead of 1.2.0.2 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 -- 1.1.0.2,
>      1.1.0.4, 1.1.0.6 as well as a few local branches 1.1.0.1000 and
>      1.1.0.1002, then the next global branch created off of 1.1 will
>      incorrectly be set to 1.1.0.1004 instead of 1.1.0.8 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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (FreeBSD)
> 
> iD8DBQFEYgevCg7APGsDnFERAomSAKDMWgJWcmOByJRv0h2J1kZrW3fGvwCfZjkR
> jtI9cRWSisG6ORRlK0CVQvE=
> =jvvC
> -----END PGP SIGNATURE-----