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 and stable release


From: Kelly F. Hickel
Subject: RE: Proposed branch tag performance patch for feature and stable release
Date: Thu, 28 Dec 2006 12:04:31 -0600

<paraphrase>Better fire up the Wayback Machine, Mr. Peabody</paraphrase>

> -----Original Message-----
> From: mdb@juniper.net [mailto:mdb@juniper.net] On Behalf Of Mark D.
> Baushke
> Sent: Tuesday, May 16, 2006 7:36 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
> 
> Kelly F. Hickel <kfh@mqsoftware.com> writes:
> 
> > <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
> 
> > > > > 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.
> > >
<snip>

[Kelly F. Hickel] 
Attached is a diff against cvs 1.11.21 for sanity.sh, before I go any
further, I'd like to make sure that the tests I've written are adequate
to test for the scenarios above (I haven't rewritten the actual revision
finder code yet).

The basic idea is to create three branches from the trunk, the first and
third branches each get a commit, then the tag for the first branch is
deleted. I then create a fourth branch, do a commit making sure that the
revision tag for the file is 1.1.8.1.

Leaving aside the CVS_LOCAL_BRANCH_NUM issue for the moment (as that's a
cvs 1.12 feature and I'm working on 1.11 first), is this a sufficiently
rigorous set of tests?  It seems to simple, but I haven't been able to
come up with a scenario where the issues that were brought up in May
would fail to be detected by this set of tests.

Thanks,


-- 

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


Attachment: diff.txt
Description: diff.txt


reply via email to

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