[kepler-dev] Tagging and Branching
Christopher Brooks
cxh at eecs.berkeley.edu
Fri Jun 20 16:18:37 PDT 2008
Hi Christopher,
Thanks for sending this around.
How I used branches and tags in CVS for Ptolemy is documented in
$PTII/doc/coding/releasemgt.htm
Basically, I usually run something like:
cvs tag -b rel-7-0-beta-2
which creates a branch.
I'll use that branch for the beta and for the final release.
I tend to add fixes to the branch after the release in case there is
another incremental release soon after the major final release. I
don't do this lightly, usually I only update the release branch with
fixes to significant problems. I really try to avoid adding new
features to the release branch after a release. I'm usually fairly
successful.
I tend not to tag releases, I just use a branch. I do use dates quite
a bit. I don't mind having tags added to the ptII repository. I'd
prefer not to have lots of branches added to the ptII repository though.
I realize this is idiosyncratic, but it is simple at it works.
I agree that branch-when-needed is preferred.
I prefer that the trunk always work and that people avoid working in
branches, it adds complexity. Most changes can be small atomic
changes that leave the tree stable. I've found that when developers
work outside the trunk for more than a few days that there can be big
problems when trying to merge.
I think that having a stable release branch that changes roughly once
a year is a win for people who want stable code and don't want to live
on head of the devel trunk.
_Christopher
--------
Hi all,
I did not get any answer to my email asking how tags and branches are
currently used in Kepler and Ptolemy. I just want to have things
clear. Please read the following summary:
SUMARRY:
TAGS ARE SNAPSHOTS AND ARE STATIC: NO CHANGES ALLOWED
BRANCHES ARE USE FOR SEPERATED DEVELOPEMENT: CHANGES ALLOWED
If you disagree, then we might have a problem and we really need to
discuss this.
Below some more details:
Tag:
A tag or label refers to an important snapshot in time, consistent
across many files. These files at that point may all be tagged with a
user-friendly, meaningful name or revision number. See the discussion
of baselines, labels, and tags.
Branch:
A set of files under version control may be branched or forked at a
point in time so that, from that time forward, two copies of those
files may be developed at different speeds or in different ways
independently of the other.
References:
http://en.wikipedia.org/wiki/Branching_(software)
http://en.wikipedia.org/wiki/Revision_tag
http://en.wikipedia.org/wiki/Revision_control
One important features of SVN is the use of global revision numbers
that are actually as accurate as tags.
Maybe cvs users should have a look at the following link:
http://svnbook.red-bean.com/en/1.1/apa.html#svn-ap-a-sect-1
Branch strategy:
There are several ways of using branches. Based on the information I
found here:
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html
The Branch-When-Needed system seams to be the best for Kepler:
Pros: /trunk is guaranteed to be stable at all times. The hassle of
branching/merging is somewhat rare.
Cons: Adds a bit of burden to users' daily work: they must compile and
test before every commit.
I hope things are clear now,
Best regards,
Crhistopher Tuot
--
______________________________________________________________
Dipl.-Ing. Christopher Tuot
DFKI GmbH (German Research Center for Artificial Intelligence)
Knowledge Management Department
POBox 2080, 67608 Kaiserslautern, Germany
fon: +49(0)631 / 20575 - 127
fax: +49(0)631 / 20575 - 103
mail: christopher.tuot at dfki.de
web: http://www.dfki.de
______________________________________________________________
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
Geschaeftsfuehrung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter
Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
More information about the Kepler-dev
mailing list