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
Received on Thu Apr 26 21:44:33 2007