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

[Kelly F. Hickel]

I just realized that I left out the strncmp!  I've added it to the
outline below, along with some examples).....
-Kelly

> -----Original Message-----
> From: Kelly F. Hickel
> Sent: Monday, May 15, 2006 11:10 AM
> To: Mark D. Baushke
> Cc: bug-cvs@nongnu.org
> Subject: RE: Proposed branch tag performance patch for feature and
stable
> releases
> 
> 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  (given current rev to branch, ex: 1.1):
> 1)  Determine number of dots (numdots) in the current revision (ex: 1)
> 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 (ex: 2 "1.1.12") AND the strings are
identical up to the numdots+1 dot (ex: strncmp("1.1.0.2", "1.1.12", 3)
AND the final term is even, insert the integer value of the final term
into the list.
>     b) if the rev has numdots+2 (ex: 2 "1.1.0.4") AND the strings are
identical up to the numdots+2 dot (ex: strncmp("1.1.0.2", "1.1.12", 5)
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-----