[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed branch tag performance patch for feature and stable release
From: |
Kelly F. Hickel |
Subject: |
RE: Proposed branch tag performance patch for feature and stable releases |
Date: |
Tue, 16 May 2006 07:41:10 -0500 |
<snip>
> > > > > > > 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.
> > > > >
> > > > > So, if you observed the following tags
> > > > >
> > > > > q:1.23.0.10
> > > > > p:1.23.0.4
> > > > > o:1.1.12.1.0.4002
> > > > > n:1.1.0.18
> > > > > m:1.1.14.22.0.2
> > > > > l:1.1.14.22.0.4
> > > > > k:1.1.0.14
> > > > > j:1.1.12.1.0.4
> > > > > i:1.1.0.10
> > > > > h:1.1.0.1000
> > > > > g:1.1.8.1.0.2
> > > > > f:1.1.0.8
> > > > > e:1.1.0.6
> > > > > d:1.1.0.4
> > > > > c:1.1.0.2
> > > > > b:1.1.0.2000
> > > > > a:1.1.1.1.0.2
> > > >
> > > > [Kelly F. Hickel] What's the significance of the
> > > > letters before the colon in the tags above? Is
> > > > that the symbolic name of the tag, or something
> > > > else?
> > >
> > > Symbolic name of the tag... I just came up with a
> > > random sampling of tags. It must be presumed that
> > > the 1.1.0.12 magic branch tag was deleted and
> > > likewise with 1.23.0.2, 1.23.0.6, and 1.23.0.8
> > > magic branches.
> >
> > [Kelly F. Hickel] OK, so how does one determine that 1.1.0.12,
> 1.23.0.2,
> > 1.23.0.6 and 1.23.0.8 existed at one point? (I'm assuming that it
> would
> > be bad to reuse those magic branch tags)
>
> CVS would not have created a magic branch tag 1.1.0.14 unless a
> 1.1.0.12
> existed previously.
>
> The fact that there also appears to be a branch 1.1.12.1.0.4002
> indicates that a 1.1.12.1 revision exists and has a local branch for
> it
> in the 4002 range. This may either have been the starting revision
> provided by the user via the CVS_LOCAL_BRANCH_NUM environment
> variable,
> or there may have once been a 1.1.12.1.0.4000 branch. We won't be able
> to tell unless there happens to be a 1.1.12.1.4000.<num> revision in
> the
> file.
>
> It may not be bad to reuse branch tags provided that there are no
> revisions created under them. In fact, I believe that CVS would choose
> 1.1.0.12 as a candidate revision and only the fact that the tagging
> code
> would parse the entire RCS file and reject 1.1.0.12 as a revision for
> a
> new tag forcing the march to 1.1.0.14, etc.
>
> -- Mark
>
[Kelly F. Hickel] OK, that clears something up, I had tried to ask last
week if I should be looking for the first gap, or the highest unused one
below CVS_LOCAL_BRANCH_NUM. I must have gotten turned around on the
answer.
But, it seems that this new code should reject 1.1.0.12, as it would be
rejected later anyway.
I'll noodle over this a bit and redo the pseudo code (and test it
against the tags you've given) and then post the newer version for
comment....
-- Kelly
> > > > > for a particular RCS file, what magic branch
> > > > > revision would your programv generate as the
> > > > > next revision for each of the given revisions:
> > > > >
> > > > > 1.1.1.2
> > > > > 1.1
> > > > > 1.24
> > > > > 1.1.2000.1
> > > > > 1.1.18.12
> > > > >
> > > > > are you able to make any assumptions about the
> > > > > existence of tags like:
> > > > >
> > > > > aa:1.1.2.23
> > > > > ab:1.1.12.14
> > > > > ac:1.23.2.16
> > > > > ad:1.1.6.1
> > > > >
> > > > > > > 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.
> > >
> > > It can be tricky, if you have cvs commands you
> > > think will demonstrate what you need, feel free to
> > > ask for help turning them into tests.
> > >
> > > -- Mark
>
> -- Mark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (FreeBSD)
>
> iD8DBQFEacdACg7APGsDnFERAhqvAJ9KYEHfKA3Zr779u30YRNehICcebACghJKu
> 9pzTStYvP8lhK1URMVVIZtQ=
> =XDt3
> -----END PGP SIGNATURE-----
- Proposed branch tag performance patch for feature and stable releases, Kelly F. Hickel, 2006/05/04
- RE: Proposed branch tag performance patch for feature and stable releases, Kelly F. Hickel, 2006/05/09
- RE: Proposed branch tag performance patch for feature and stable releases, Kelly F. Hickel, 2006/05/15
- RE: Proposed branch tag performance patch for feature and stable releases, Kelly F. Hickel, 2006/05/16
- RE: Proposed branch tag performance patch for feature and stable releases, Kelly F. Hickel, 2006/05/16
- RE: Proposed branch tag performance patch for feature and stable releases, Kelly F. Hickel, 2006/05/16
- RE: Proposed branch tag performance patch for feature and stable releases,
Kelly F. Hickel <=