Confusion regarding gdb_5_1_1-2002-01-24-release tag

Confusion regarding gdb_5_1_1-2002-01-24-release tag

[Paul Hilfinger]

No doubt this question simply reflects my aversion to CVS, but here goes:
a cvs log run on gdb/value.h shows that tag gdb_5_1_1-2002-01-24-release
is defined as 1.21.  Revision 1.21 of gdb/value.h is dated 2001/05/21.  
Revision 1.26 is dated 2002/01/04.  This appears not to be the only
example.  What gives?

Thanks.

Paul

Re: Confusion regarding gdb_5_1_1-2002-01-24-release tag

[Andrew Cagney]

> No doubt this question simply reflects my aversion to CVS, but here goes:
> a cvs log run on gdb/value.h shows that tag gdb_5_1_1-2002-01-24-release
> is defined as 1.21.  Revision 1.21 of gdb/value.h is dated 2001/05/21.  
> Revision 1.26 is dated 2002/01/04.  This appears not to be the only
> example.  What gives?
> 
> Thanks.

Looking at the branch/point tags:

         gdb_5_1-2001-07-29-branch: 1.20.0.4
         gdb_5_1-2001-07-29-branchpoint: 1.20

         gdb_5_1_1-2002-01-24-release: 1.20

GDB's releases are drawn from a branch.  After the branch was cut a 
number of changes on the trunk were made but never on the branch.

See if you can find a tool for browsing CVS branches (tkcvs on 
sourceforge?, others?).  It makes life a lot easier.

enjoy,
Andrew

Re: Confusion regarding gdb_5_1_1-2002-01-24-release tag

[Andreas Schwab]

Andrew Cagney <ac131313@cygnus.com> writes:

|> > No doubt this question simply reflects my aversion to CVS, but here goes:
|> > a cvs log run on gdb/value.h shows that tag gdb_5_1_1-2002-01-24-release
|> > is defined as 1.21.  Revision 1.21 of gdb/value.h is dated 2001/05/21.
|> > Revision 1.26 is dated 2002/01/04.  This appears not to be the only
|> > example.  What gives?
|> > Thanks.
|> 
|> Looking at the branch/point tags:
|> 
|>          gdb_5_1-2001-07-29-branch: 1.20.0.4
|>          gdb_5_1-2001-07-29-branchpoint: 1.20
|> 
|>          gdb_5_1_1-2002-01-24-release: 1.20
|> 
|> GDB's releases are drawn from a branch.  After the branch was cut a number
|> of changes on the trunk were made but never on the branch.
|> 
|> See if you can find a tool for browsing CVS branches (tkcvs on
|> sourceforge?, others?).  It makes life a lot easier.

The viewcvs interface on savannah has a pretty nice feature: you can get
a graphical revision tree for a file.  Maybe this could be made available
on sourceware as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Confusion regarding gdb_5_1_1-2002-01-24-release tag

[Paul Hilfinger]

Ah, I see.  Sorry; I reacted hastily.  Thanks.

Paul

Re: Confusion regarding gdb_5_1_1-2002-01-24-release tag

[cgd]

At Tue, 12 Mar 2002 10:49:38 +0000 (UTC), "Paul Hilfinger" wrote:
> No doubt this question simply reflects my aversion to CVS, but here goes:

heh.

> a cvs log run on gdb/value.h shows that tag gdb_5_1_1-2002-01-24-release
> is defined as 1.21.  Revision 1.21 of gdb/value.h is dated 2001/05/21.  
> Revision 1.26 is dated 2002/01/04.  This appears not to be the only
> example.  What gives?

(Actually, first, i'm puzzled: i looked at
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/value.h?cvsroot=src&only_with_tag=gdb_5_1-2001-07-29-branch
and it shows that tag being on rev 1.20, not 1.21.  Since that
revision also corresponds to the date you mentioned, I'll assume you
mistyped the rev #.)


Anyway, revisions tagged with that tag (gdb_5_1_1-2002-01-24-release,
the 5.1.1 release tag) were taken from the 5.1 branch (the branch tag
with name gdb_5_1-2001-07-29-branch, which corresponds to
pseudo-revision 1.20.0.4).

Expressed in cvs commands, that's probably something like:

	cvs rtag -r gdb_5_1-2001-07-29-branch \
		gdb_5_1_1-2002-01-24-release \
		module_list

(possibly with a -D "date" thrown in, depening on Andrew's style.)

So, the current state _of that branch_ is what was tagged.

If there had been modifications _on the branch_ to the file, they
would have been in a revision number 1.20.X.Y, and that's what would
have been tagged.

However, there weren't, so the revision corresponding to the base of
the branch (1.20) was tagged.


Revision 1.26 is on the 'trunk' of development, not on a branch.
Since the branch was being tagged, as described above rev. 1.20 was
tagged instead.


(FWIW, looking at this file with cvsweb makes me doubt the veracity of
cvsweb.  cvsweb doesn't list rev 1.20 as branchpoint for that branch,
and instead only lists that branch tag as a tag on rev 1.20.  That's a
bit confusing.)


"Hope that helps!"  8-)


chris