geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Old branches (was: Old tags in Geornimo)
Date Wed, 02 Nov 2005 19:15:47 GMT
On 11/2/05, Dain Sundstrom <dain@iq80.com> wrote:
> On Nov 2, 2005, at 9:18 AM, Bruce Snyder wrote:
>
> > On 11/2/05, Dain Sundstrom <dain@iq80.com> wrote:
> >
> >
> >> I suggest next time we are creating a milestone, preview or tag only
> >> (unsupported) release, we don't create the temp branch in branches.
> >>
> >
> > I respectfully disagree with this idea and my reasons are simple -
> > tags are meant to mark a point in time and *should not change* (i.e.,
> > commits to a tag should not happen). If a tag needs to change (i.e.,
> > something needs to be committed to it) then that tag figuratively
> > becomes a branch (and should therefore be moved to the branches dir).
>
> You know, I think the big problem here is we are trying to apply CVS
> terminology and dogma developed due to the limitations of CVS.  In
> CVS, the dogma is you never create a branch from a tag, always branch
> then tag.  In subversion there is no difference between a tag and a
> branch and we can easily change between them.  The difference lives
> in how we treat them.

Yes, it is a figurative and semantic difference (unless one implements
some sophisticated commit hooks to disable committing to a tag).
However, the concepts of tags vs. branches does not change from CVS to
SVN - tags are meant to be static whereas branches are meant to be
lines of development. In fact, here's a message from the svn-user@
mailing list supporting this notion:

    http://svn.haxx.se/users/archive-2003-09/0021.shtml

> I get the feeling that this debate is in a quagmire because we do not
> have a common set of definitions for the terms we are using, so let's
> formally define them.

Actually, I agree completely with this statement. Agreement on terms
and their definitions is more meaningful than any other concept
really.

> I think we have the following categories for
> code lines in our repository:
>
> supported code line (mutable)
> snapshot code line (immutable)
> experimental code line
> ?? others ??
>
> The nice thing with subversion is we can switch a code line between
> the three groups with zero impact to history and development.  We can
> simply move a code line to a new category, or create a copy of a code
> line in a new category.

Exactly ;-).

> Another big problem we have is creating a snapshot line is can not
> atomic operation.  Subversion is more then willing to make an atomic
> copy, but we can not create a snapshot code line without modifying
> the build and sometimes the code, and then there is certification
> testing which sometimes requires modification to the code line.  I
> think how we handle the hand off from a supported code line to a
> snapshot code line is at the heart of this debate.

Yes, and this is a very common dilemma. The recommended procedure is
the following set of steps:

1) Create a tag from HEAD named tag_foo1
2) Create a branch from tag_foo named tag_foo1_branch
3) Do work
4) Create a tag from tag_foo1_branch named tag_foo2
5) Remove tag_foo1_branch accordingly

The reasons for making the two tags is many, but the most important
one is to easily create a diff between the start and the end of the
development. This covers any need to merge changes back into HEAD from
the work done on the branch. In addition, copies are cheap in
Subversion so creating many, many tags has little impact on the
server.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Mime
View raw message