Maybe I need to be clearer about how we use the trunk today and how it
is different than the "new" approach.
Here is our branching structure today and I think that other svn groups
use the same (or approximately the same) approach:
R1
/--------------------------------------
/
/
/ R2
/ /------------------------
/ /
/ / R3
/ / /---------------
/ / /
/ / /
R1 / R2 / R3 / R4
Trunk---------/-------------------------------------------------------
Horizontal lines are branches (and trunk). Diagonal lines are branches.
1. Whenever we start a new release, we branch for the previous release
and start the new release on the trunk. I.e. every release lives on the
trunk for a while and then moves to a release branch.
2. All release branches are branched from the trunk.
3. The trunk exists as long as the application does.
4. Our merge pattern is always R1 -> R2 -> R3 -> R4.... -> Rn
The new approach is like this:
R1-----------------------
\
\
\
R2 \------------------------
\
\
\
R3 \------------------------
\
\
\
R4 \------------------------
Horizontal lines are branches. There is not trunk in the sense that
every development stream (dir) is treated exactly the same.
1. Whenever we start a new release R, it branches off of R-1 (not the
trunk).
2. A release lives as long as it is active on a single branch. (It never
hops from trunk to branch.
3. There is no trunk, i.e. special dir that exists for the duration of
the app and is treated differently from release branches.
4. Like the previous approach, merging is still R1 -> R2 -> R3 -> R4 ...
-> RN.
I can see no advantage of the first approach over the second, and the
second seems simpler. And, for me, all other things equal, simpler is
better.
> -----Original Message-----
> From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
> Sent: Thursday, April 26, 2007 2:44 PM
> To: users@subversion.tigris.org
> Subject: RE: Re: Why have a trunk dir, anyway?!
>
>
> Hmm, in this approach, the trunk is just renamed.
> In R1, it was called R1. In R2, it was called R2,
> etc.
>
> Also, with this approach, what happens if a problem
> is found in RN-1, after RN already branched, with RN's
> respective branches?
>
> >-----Original Message-----
> >From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
> >Sent: Thursday, April 26, 2007 3:38 PM
> >To: Josh Gilkerson; Fouts Christopher (QNA RTP PT PREV)
> >Cc: users@subversion.tigris.org
> >Subject: RE: Re: Why have a trunk dir, anyway?!
> >
> >To me it seems that there are a couple of differences.
> >
> >First, with the "proposed" structure, there is no "trunk"
> >directory that is continually maintained. Instead, every
> >development stream , i.e.
> >branch, is dedicated to a particular release. When that
> >release is obsolete, the branch can be retired (deleted).
> >With the proposed structure, all branches are treated uniformly.
> >
> >The standard svn "trunk" directory isn't like that. Over time,
> >it is where all releases start. Later, those releases move to
> >a "release"
> >branch. And the trunk can never be retired. With the
> >"standard" braching structure, all branches are not treated
> uniformly.
> >
> >Secondly, and I'm not sure that it matters, but with the
> >proposed structure, release branch R is always branched off of
> >release branch R-1. With the "standard" approach, at least as
> >I understand it, all release branches are branched from the trunk.
> >
> >I guess the thing I like most about the "proposed" structure
> >is that it is simpler. There doesn't seem to be any need for a
> >subversion "trunk"
> >directory that is handled differently than "release" branches.
> >
> >
> >> -----Original Message-----
> >> From: Josh Gilkerson [mailto:jwg@google.com]
> >> Sent: Thursday, April 26, 2007 2:05 PM
> >> To: Chris.Fouts@qimonda.com
> >> Cc: users@subversion.tigris.org
> >> Subject: Re: Why have a trunk dir, anyway?!
> >>
> >>
> >> It seems to me that your scheme is no different from the trunk
> >> approach except for the way things are labeled (for
> subversion, that
> >> is).
> >>
> >> This tree is basically the same as yours, but the pipes are
> >the trunk.
> >> and the parts that are the same are branches.
> >>
> >> R1
> >> |||||||||||----------------
> >> |
> >> | R2
> >> ||||||||||||--------------
> >> |
> >> | R3
> >> ||||||||------------------
> >> |
> >> | R4
> >> |||||---------------------
> >> |
> >>
> >>
> >> On 4/26/07, Chris.Fouts@qimonda.com
> <Chris.Fouts@qimonda.com> wrote:
> >> > You just called a "kettle' a "pot."
> >> >
> >> > >-----Original Message-----
> >> > >From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
> >> > >Sent: Thursday, April 26, 2007 2:31 PM
> >> > >To: users@subversion.tigris.org
> >> > >Cc: Hartleroad, James M [EQ]; Smythe, Susan M [EQ]
> >> > >Subject: Why have a trunk dir, anyway?!
> >> > >
> >> > >A very intuitive branching structure, often the first one
> >> that people
> >> > >think of in my experience, is:
> >> > >
> >> > >R1
> >> > >---------------------------
> >> > > \
> >> > > \ R2
> >> > > \-------------------------
> >> > > \
> >> > > \ R3
> >> > > \-------------------------
> >> > > \
> >> > > \ R4
> >> > > \-------------------------
> >> > > .
> >> > > .
> >> > > .
> >> > >
> >> > >Now, with CVS you couldn't do this because you would
> >> become further
> >> > >and further diverged from the trunk. And, with CVS,
> >> deleting branches
> >> > >wasn't really an option.
> >> > >
> >> > >However, with Subversion, the branching scheme above seems
> >> perfectly
> >> > >do-able, at least as far as I can see. Especially, if
> you do away
> >> > >with the concept of the trunk. Instead of having:
> >> > >
> >> > >
> >> > >Proj/
> >> > > trunk/
> >> > > branches/
> >> > > tags/
> >> > >
> >> > >You might have something like:
> >> > >
> >> > >Proj/
> >> > > releases/
> >> > > R1/
> >> > > main/
> >> > > branches/
> >> > > tags/
> >> > > R2/
> >> > > main/
> >> > > branches/
> >> > > tags/
> >> > >
> >> > >When a new release RN needs to start, just branch off of
> >> RN-1. As new
> >> > >release goes into production, old releases can be retired
> >> (deleted).
> >> > >
> >> > >So, my question is, why do we need the trunk concept
> >anyway? Is it
> >> > >just because we've been conditioned by CVS that you have
> >to have a
> >> > >trunk. Or, are there valid reasons? Also, can anyone see
> >a problem
> >> > >with the second of the two branching structures described above?
> >> > >
> >> > >All comments appreciated. Thanks.
> >> > >
> >> > >Chuck
> >> > >
> >> > >
> >> >
> >>
> >>------------------------------------------------------------
> ---------
> >> > >To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> > >For additional commands, e-mail:
> users-help@subversion.tigris.org
> >> > >
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> > For additional commands, e-mail: users-help@subversion.tigris.org
> >> >
> >> >
> >>
> >>
> >> --
> >> Josh Gilkerson
> >> Software Engineer
> >> Google, Inc * MV-1600 Plymouth (HQ)
> >> +1 (650) 253-1667 direct
> >> +1 (859) 608-7827 cell
> >> jwg@google.com
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: users-help@subversion.tigris.org
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 26 22:23:31 2007