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: [email protected] > 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 > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. > > Baushke > > Sent: Wednesday, May 10, 2006 10:33 AM > > To: Kelly F. Hickel > > Cc: [email protected] > > 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----- _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
