bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] New release number 0.9.0-1


From: Massimiliano Maini
Subject: Re: [Bug-gnubg] New release number 0.9.0-1
Date: Mon, 31 Mar 2008 17:33:36 +0200



address@hidden wrote on 31/03/2008 15:48:24:

> * Christian Anthon <address@hidden> [080331 14:11]:
> > >
> > >  I think it's enough to just Tag the code?
> > >  Jon
> >
> > If we are to follow your original suggestion about the road to 1.0,
> > then tagging is the right way to do it. We are not planning to
> > maintaining these sub-releases, but tagging them makes things easier
> > to track.
>
> I'm a bit puzzled ... there is already a non-branch tag "rel-0.9.0." I
> also don't understand the difference between "branch" and "non-branch
> tags" as seen at
> http://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/?pathrev=.

A (normal, non-branch) tag is just a tag that indicates with a single string (like
"rel-0.9.0") a given version of the entire set of files of the project. It can be
used to check out that precise version, or to check the differences with respect to
that version (and to do other more complicate things).

A branch tag creates a separate trunk in the CVS repository (on top of the usual
MAIN trunk). A developper can commit a change to the MAIN trunk without affecting
the other branch (rel-0.9.0).
Imagine we reach a stable version 1.0 and we create a new branch for that.
Then Jon and Christian starts a major change in the code (separate the interface from
the playing engine or a major GUI redisegn or whatever): they can keep on committing
in the MAIN trunk, the stable branch will be unaffected.
Now imagine also that a bug is found in the stable branch: a fix can be committed in
the stable branch only (even if this is unusual: most of the time you want to apply
the fix to the main trunk too, which you can do, of course).
Sometimes, part of the chages you've done in the main trunk needs to be merged in the
stable branch. This is possible (but a bit tricky).

When you checkout the code from your repository, if you ask for a specific non-branch
tag, you check out exactly the version specified by the tag.
On the other hand, if you checkout specifying a branch tag, you will check out the most
recent version of each file *in the branch trunk*.

I also thinkn that it is generally suggested, when creatnig a new branch, to first
create a non branch tag and then a branch one 9exactly on the same version of the
files): this makes it easier to do a diff between the most recent files on the branch
trunk and "the base of the branch" (the point on the main trunk where the branch
started).

In any CVS-related documentation you should find a graphical illustration of the
branch thing.

MaX.


reply via email to

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