Re: GDB 5.1.1 scheduled 00:00 24 Jan 2002 GMT

[Jason Molenda <jason-swarelist at molenda dot com>]

On Thu, Jan 17, 2002 at 04:06:57PM -0500, Andrew Cagney wrote:
> I'm planning on creating a GDB 5.1.1 from the head of the GDB 5.1 branch 
> on or about 24 January 2002 GMT.

It is traditional cvs usage to do all 5.1.* releases off of a single
branch, the gdb-5_1-branch.  Creating a new branch for the 5.1.1
changes gains you little but some juked up cvs branch structure.
If a 5.1.2 release happens, would that be based off of the 5.1
branch, or another branch branched off the tip of 5.1.1?  What if
a 5.1.1a had to be made to correct something small?  If a 5.1.1.1a
branch happens and a 5.1.2 has to happen, does that mean the 5.1.2
is branched off the tip of 5.1.1a branch or 5.1.1?

I know the gdb releases won't be so complicated, but why start a
precedent like this?  Instead, a single branch, gdb-5_1-branch,
can be used for all of these.  You tag the releases, so when 5.1
is released you put a tag like gdb-5_1-release on it.  You continue
to check in small patches to gdb-5_1-branch.  When 5.1.1 is ready,
you add another tag, gdb-5_1_1-release.  5.1.1a?  More checkins on
the 5.1 branch, another -release tag.  Same thing for 5.1.2.

Incidentally, this also touches on a style nit of mine that I've
talked to Andrew about in the past in direct mail, but I'm strongly
opposed to encoding dates in the branch names.  The thinking behind
gdb-5_1-20010914-branch (or whatever it was) is that you can guess
when the sources were branched off the trunk.  If that's an important
piece of information, encode it in the branchpoint tag
(gdb-5_1-2001-09-14-branchpoint) which people rarely have to type
on their own, and call the branch something sensible like
gdb-5_1-branch.  By encoding the date in the branch tag, which
people have to use often, you make them remember arbitrary information
which doesn't disambiguate anything.  I can check out a copy of
the gcc 3.0 branch without looking at a single web page, without
checking a single tag list -- any reasonable person can guess what
it will look like.  No reasonable person can guess what the gdb
5.1 branch name might be.  You could just as easily include a few
bytes of /dev/random in there for all it does.

I apologize if I come off sounding overly indignant about this,
but it's really annoying and I shake my head in disappointment each
time see this practice becoming codified or think about it being
emulated in future branches.

Jason