I see no less work when merging changes between
RN and RN-1; hence to me it's at least no better,
it may even be worse since I'd have to
- Merge RN-1 branch(es) to RN-1 main;
- Merge RN-1 main to RN main
- Merge RN main to RN branch(es)
Like I said it does NOT matter what you call it, you still
have a trunk.
...IMO
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Thursday, April 26, 2007 4:23 PM
>To: Fouts Christopher (QNA RTP PT PREV); users@subversion.tigris.org
>Subject: RE: RE: Re: Why have a trunk dir, anyway?!
>
>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 Fri Apr 27 14:36:25 2007