bug-cvs
[Top][All Lists]
Advanced

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

RE: Proposed branch tag performance patch for feature


From: Kelly F. Hickel
Subject: RE: Proposed branch tag performance patch for feature
Date: Thu, 4 Jan 2007 10:12:44 -0600

<snip>
> 
> I have ported the patch to FEATURE and will commit there if it passes
> all of the sanity checks. The diff for this variation of the patch is
in
> another email. Please advise if you see anything suspecious looking.
> 
>       Thanks,
>       -- Mark
<snip>

Thanks for that Mark, the whole reason I started with the stable branch
was that I don't really understand the whole CVS_LOCAL_BRANCH_NUM very
well.

Good news first, I applied both your feature and stable patches to cvs
checked out versions, built and ran the sanity tests with no issues.
The feature branch actually edged out the stable branch by just over 1
minute (out of 12 minutes). 

The not as good news, quite possibly to the above mentioned non-groking
of CVS_LOCAL_BRANCH_NUM, it looks to me that the feature patch is
probably wrong.  Looks like your using that to set the defaultrv param
to findnextmagicrev, but that parameter is only used if
findnextmagicrev_proc returns an empty list (no candidate revisions, or
some error). I had imagined that the patch for the feature release would
have to go through the sorted list of revisions and find the highest
value that was less than CVS_LOCAL_BRANCH_NUM and start there.  The
other possibility that I came up with (in case I flipped the meaning of
CVS_LOCAL_BRANCH_NUM) was that, if the highest found revision was less
than CVS_LOCAL_BRANCH_NUM, then I'd have to start from
CVS_LOCAL_BRANCH_NUM.  It hinges on whether CVS_LOCAL_BRANCH_NUM means
that when branching on this repo one needs to create a magic branch tag
with a revision above CVS_LOCAL_BRANCH_NUM, or if it needs to be less
than CVS_LOCAL_BRANCH_NUM.

The way the feature patch currently is set up, most of the time
CVS_LOCAL_BRANCH_NUM isn't going to figure in the calculation at all,
which I suspect is the wrong thing. And, there probably needs to be a
sanity.sh test for whichever is the correct behavior, and I really don't
have any idea how to write that test (although I might, once the issues
in the previous paragraph are resolved).

-Kelly




reply via email to

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