You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com> on 2007/04/26 18:30:34 UTC
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
Re: Why have a trunk dir, anyway?!
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 4/26/2007 3:10 PM, Irvine, Chuck R [EQ] wrote:
>
>> -----Original Message-----
>> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
>> Sent: Thursday, April 26, 2007 1:59 PM
>> To: Irvine, Chuck R [EQ]
>> Cc: users@subversion.tigris.org; Hartleroad, James M [EQ];
>> Smythe, Susan M [EQ]
>> Subject: Re: Why have a trunk dir, anyway?!
>>
>>
>> On 4/26/2007 2:30 PM, Irvine, Chuck R [EQ] wrote:
>> > 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?
>>
>> An advantage of the standard layout is that new development always
>> occurs in the same place, /trunk. I don't need to svn switch
>> my working
>> copy every time someone else decides we're ready to start
>> working on a
>> new release. With your scheme, sometimes I'd be in the
>> middle of work
>> in R1/main when the release process starts, and I'd have to
>> remember to
>> switch to R2/main before committing, or risk contaminating
>> the release.
>>
>
> Maybe there is something different between the way our two companies do
> development. Here, if a developer is in the middle of, say, R1
> functionality, and R2 kicks off, he doesn't switch his workspace to R2,
> since he's on the R2 team. He continues to commit to the R1 development
> stream. His changes will get propagated to R2 via merging.
I'm working on an open source project, so there's nobody else to do the
merging: we'll discuss it if it's not obvious it should be done, but if
it gets done, it'll be me who does it. There are about 20 committers to
whom this applies equally. Since there's a lot of variability in how
much time each of us spend on the project, it's important to keep things
simple. That means a consistent workflow is important:
- Get an idea, talk about it, decide to implement it. (For small bug
fixes this is all pretty quick, just announcing "I'll fix it".)
- Implement it on the trunk (or a private branch if it's bigger); once
it's working, commit to the trunk.
- Decide if it belongs in the active release branch, and if so merge
there.
We generally only have the trunk and one branch active, though for short
periods of time near a release there might be two branches active: but
there's a lot of resistance to that, because we are really tight on
volunteer resources.
I can see commercial development where you've got the resources to
assign people to individual branches would have different needs, but
here it's good to almost always have the flow from the trunk out to the
branches, because one kind of flow is easier to get right than two or more.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
> Sent: Thursday, April 26, 2007 1:59 PM
> To: Irvine, Chuck R [EQ]
> Cc: users@subversion.tigris.org; Hartleroad, James M [EQ];
> Smythe, Susan M [EQ]
> Subject: Re: Why have a trunk dir, anyway?!
>
>
> On 4/26/2007 2:30 PM, Irvine, Chuck R [EQ] wrote:
> > 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?
>
> An advantage of the standard layout is that new development always
> occurs in the same place, /trunk. I don't need to svn switch
> my working
> copy every time someone else decides we're ready to start
> working on a
> new release. With your scheme, sometimes I'd be in the
> middle of work
> in R1/main when the release process starts, and I'd have to
> remember to
> switch to R2/main before committing, or risk contaminating
> the release.
>
Maybe there is something different between the way our two companies do
development. Here, if a developer is in the middle of, say, R1
functionality, and R2 kicks off, he doesn't switch his workspace to R2,
since he's on the R2 team. He continues to commit to the R1 development
stream. His changes will get propagated to R2 via merging.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Why have a trunk dir, anyway?!
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 4/26/2007 2:30 PM, Irvine, Chuck R [EQ] wrote:
> 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?
An advantage of the standard layout is that new development always
occurs in the same place, /trunk. I don't need to svn switch my working
copy every time someone else decides we're ready to start working on a
new release. With your scheme, sometimes I'd be in the middle of work
in R1/main when the release process starts, and I'd have to remember to
switch to R2/main before committing, or risk contaminating the release.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Why have a trunk dir, anyway?!
Posted by Ch...@qimonda.com.
I should've said, the "trunk" is just "copied"
to a different name, then the old name deleted;
hence, it is just essentially renamed (moved).
>-----Original Message-----
>From: Fouts Christopher (QNA RTP PT PREV)
>Sent: Thursday, April 26, 2007 3: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 <Ch...@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
RE: RE: Re: Why have a trunk dir, anyway?!
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>:
> 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.
I'm not sure every stream is treated exactly the same _all the time_.
As someone else illustrated with pipes in an earlier message, there is
still an implicit trunk. Take R3 for example, it has to be treated
differently depending on which point you are on R3. If you are
somewhere on the "trunk", i.e., one of the backslashes above, it's the
same just-code-away as in the classical trunk approach. As soon as R4
is created, the dashes portion of R3 becomes effectively a branch,
where you have to remember to merge changes into R4.
--
JX
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Why have a trunk dir, anyway?!
Posted by Ed Hillmann <ed...@gmail.com>.
[snip]
What I take out of this thread is the fact the Subversion itself
doesn't force any set structure on its users, allowing them to tailor
the structure that best suits the development process using it. And
that's got to be a good thing.
For me, the trunk/branches/tags works just fine. But that doesn't
mean that it works for everyone. That's fine too. Subversion is
flexible enough to support these both. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
[snip]
> >>> We have very well defined requirements for each release. And if we
> >>> adopt this branching scheme, we will have in our repository
> >>>
> >>> Repo/application/
> >>> release1/
> >>> release2/
> >>> release3/
> >>> ...
> >>>
> >>> So developers are very clear where they should be working.
> >> And once a
> >>> release dir (branch) is created the development for that release
> >>> always stays on the same branch (and doesn't at some point
> >> jump to a
> >>> release branch).
> >>>
> >>> Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do
> >>> this my merging R1 -> R2 -> R3, etc.
> >> Doesn't that lose a lot of the development history log
> >> compared to doing
> >> all pre-release work that doesn't absolutely have to
> isolate your
> >> developers on the trunk and branching only when it is time to
> >> stabilize
> >> the releases?
> >
> > I don't know what is meant by "losing development history log". You
> > can always look at the history of the top level "application"
> > directory.
>
> If you look at a file in the 'release3' branch, can you see all the
> individual commits in its history with useful comments as you
> would if
> you did all the work in the trunk and viewed from there or
> just a bunch
> of 'merged from' aggregates for the changes done elsewhere?
>
No, I don't think so, not if you look in the release3. However, you
invoke "svn log --verbose" on the "application" directory, you'll see
all revisions from the time the application was created. You would have
to grep for entries containing the object that you are interested in.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Why have a trunk dir, anyway?!
Posted by Les Mikesell <le...@gmail.com>.
Irvine, Chuck R [EQ] wrote:
>
> [snip]
>> Irvine, Chuck R [EQ] wrote:
>>> We have very well defined requirements for each release. And if we
>>> adopt this branching scheme, we will have in our repository
>>>
>>> Repo/application/
>>> release1/
>>> release2/
>>> release3/
>>> ...
>>>
>>> So developers are very clear where they should be working.
>> And once a
>>> release dir (branch) is created the development for that release
>>> always stays on the same branch (and doesn't at some point
>> jump to a
>>> release branch).
>>>
>>> Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do
>>> this my merging R1 -> R2 -> R3, etc.
>> Doesn't that lose a lot of the development history log
>> compared to doing
>> all pre-release work that doesn't absolutely have to isolate your
>> developers on the trunk and branching only when it is time to
>> stabilize
>> the releases?
>
> I don't know what is meant by "losing development history log". You can
> always look at the history of the top level "application" directory.
If you look at a file in the 'release3' branch, can you see all the
individual commits in its history with useful comments as you would if
you did all the work in the trunk and viewed from there or just a bunch
of 'merged from' aggregates for the changes done elsewhere?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
[snip]
> Irvine, Chuck R [EQ] wrote:
> > We have very well defined requirements for each release. And if we
> > adopt this branching scheme, we will have in our repository
> >
> > Repo/application/
> > release1/
> > release2/
> > release3/
> > ...
> >
> > So developers are very clear where they should be working.
> And once a
> > release dir (branch) is created the development for that release
> > always stays on the same branch (and doesn't at some point
> jump to a
> > release branch).
> >
> > Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do
> > this my merging R1 -> R2 -> R3, etc.
>
> Doesn't that lose a lot of the development history log
> compared to doing
> all pre-release work that doesn't absolutely have to isolate your
> developers on the trunk and branching only when it is time to
> stabilize
> the releases?
I don't know what is meant by "losing development history log". You can
always look at the history of the top level "application" directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Why have a trunk dir, anyway?!
Posted by Les Mikesell <le...@gmail.com>.
Irvine, Chuck R [EQ] wrote:
> We have very well defined requirements for each release. And if we adopt
> this branching scheme, we will have in our repository
>
> Repo/application/
> release1/
> release2/
> release3/
> ...
>
> So developers are very clear where they should be working. And once a
> release dir (branch) is created the development for that release always
> stays on the same branch (and doesn't at some point jump to a release
> branch).
>
> Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do this
> my merging R1 -> R2 -> R3, etc.
Doesn't that lose a lot of the development history log compared to doing
all pre-release work that doesn't absolutely have to isolate your
developers on the trunk and branching only when it is time to stabilize
the releases?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
We have very well defined requirements for each release. And if we adopt
this branching scheme, we will have in our repository
Repo/application/
release1/
release2/
release3/
...
So developers are very clear where they should be working. And once a
release dir (branch) is created the development for that release always
stays on the same branch (and doesn't at some point jump to a release
branch).
Yes, R1 changes have to get propagated to R2, R2 to R3, etc. We do this
my merging R1 -> R2 -> R3, etc.
Chuck
> -----Original Message-----
> From: Redman, Joel L [mailto:joel.redman@siemens.com]
> Sent: Friday, April 27, 2007 10:58 AM
> To: users@subversion.tigris.org
> Subject: RE: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
> How can you keep track of what goes where? I assume that the
> features from future release 1 have to be in future release 2?
>
>
> Joel
>
> -----Original Message-----
> From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
> Sent: Friday, April 27, 2007 11:53 AM
> To: Redman, Joel L
> Cc: users@subversion.tigris.org
> Subject: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
>
> > -----Original Message-----
> > From: Redman, Joel L [mailto:joel.redman@siemens.com]
> > Sent: Friday, April 27, 2007 10:48 AM
> > To: Irvine, Chuck R [EQ]
> > Cc: users@subversion.tigris.org
> > Subject: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
> >
> >
> > IMHO, the trunk shows how your project has changed over time,
> > release is snapshots which should never be modified
> > thereafter, barring horrible horrible bugs, and branch is
> > active changes, which may or may not be complete and ready to
> > merge into trunk. That concept gets lost without a trunk.
> > Conceptually Scheme 2 says that each release is equal and
> > equally likely to be modified.
>
> That is probably the crucial point. Like it or not (and I
> don't) where I work there will often be multiple releases in
> development concurrently. Two in active development and one
> in production is fairly common.
>
> >
> > Otherwise, your trunk is implicit, starting from ground 0 and
> > following each line up. Depends on what you want to track I
> > suppose, or at least where you want to track it.
> >
> >
> > R4 tttttttttttttttttttttttt
> > t
> > t
> > t
> > R3 tttttttttt------------
> > t
> > t
> > t
> > R2-tttttttt--------------
> >
> >
> > Joel
> >
> > -----Original Message-----
> > From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
> > Sent: Friday, April 27, 2007 11:36 AM
> > To: Chris.Fouts@qimonda.com; users@subversion.tigris.org
> > Subject: RE: RE: RE: Re: Why have a trunk dir, anyway?!
> >
> >
> > > 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)
> >
> > Don't understand. There isn't an RN-main and a RN-branch.
> > There is only one branch for each of R1, R2, R3, etc.
> >
> > >
> > > Like I said it does NOT matter what you call it, you still have a
> > > trunk.
> >
> > There is nothing in the second scheme like trunk in the first
> > scheme. Say, for illustration purposes, you always have three
> > releases going concurrently. When the the oldest release is
> > retired, a new one starts. So, the first three-release
> > situation is as shown below.
> >
> >
> > Scheme 1 (SVN Standard):
> >
> > Each release starts on the trunk and *moves* to a release
> > branch when the next release started.
> >
> >
> >
> > R1
> > /-----------------------
> > /
> > /
> > / R2
> > / /----------------
> > / /
> > / /
> > / /
> > R1 / R2 / R3
> > Trunk--------/--------------------------------------------
> >
> >
> > Scheme 2 (Homogenous Release Branches)
> >
> > Each release starts on a branch and *stays* on the branch
> > until it is retired. Each new release RN branches off of RN-1
> > (not the trunk).
> >
> >
> >
> > R3 /----------------------
> > /
> > /
> > /
> > R2 /---------------------
> > /
> > /
> > /
> > R1-----------------------
> >
> >
> >
> > Now say that you retire R1 and start R4. The new situation
> looks like:
> >
> >
> > R2
> > /----------------
> > /
> > / R3
> > / /------------------
> > / /
> > / /
> > R2 / R3 / R4
> > Trunk----------------------------------------------------
> >
> > The R1 release branch was retired (and deleted from the
> > repository). R3 was moved to a release branch. R4 now lives
> > on the trunk.
> >
> >
> > Scheme 2 (Homogenous Release Branches)
> >
> > Each release starts on a branch and *stays* on the branch
> > until it is retired. Each new release RN branches off of RN-1.
> >
> >
> >
> > R4 /----------------------
> > /
> > /
> > /
> > R3 /---------------------
> > /
> > /
> > /
> > R2-----------------------
> >
> > The original R1 branch was deleted from the repository. R3
> > stays on its original branch. R4 starts (and will stay until
> > retirement) on a branch taken from R3 (and not from the trunk).
> >
> > The point is, for the 1st scheme, all releases start the trunk and
> > *move* to a release branch. The trunk exists for the life of
> > the application. In the second scheme, each release stays on
> > it's original branch until the release is retired. And, there
> > is no *trunk* branch
> > (dir) that lives for the life of the application.
> >
> > If anyone is still with me at this point, my purpose isn't
> > really to say that the second scheme is *better*. I was just
> > trying to see if anyone could see any problems with using it.
> > So far, we've done quite a bit of experimentation and can see
> > no problems. But... Being new to SVN, there are lots of folks
> > that have more insight than us.
> >
> > 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
>
> ---------------------------------------------------------------------
> 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
RE: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
Posted by "Redman, Joel L" <jo...@siemens.com>.
How can you keep track of what goes where? I assume that the features
from future release 1 have to be in future release 2?
Joel
-----Original Message-----
From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
Sent: Friday, April 27, 2007 11:53 AM
To: Redman, Joel L
Cc: users@subversion.tigris.org
Subject: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
> -----Original Message-----
> From: Redman, Joel L [mailto:joel.redman@siemens.com]
> Sent: Friday, April 27, 2007 10:48 AM
> To: Irvine, Chuck R [EQ]
> Cc: users@subversion.tigris.org
> Subject: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
> IMHO, the trunk shows how your project has changed over time,
> release is snapshots which should never be modified
> thereafter, barring horrible horrible bugs, and branch is
> active changes, which may or may not be complete and ready to
> merge into trunk. That concept gets lost without a trunk.
> Conceptually Scheme 2 says that each release is equal and
> equally likely to be modified.
That is probably the crucial point. Like it or not (and I don't) where I
work there will often be multiple releases in development concurrently.
Two in active development and one in production is fairly common.
>
> Otherwise, your trunk is implicit, starting from ground 0 and
> following each line up. Depends on what you want to track I
> suppose, or at least where you want to track it.
>
>
> R4 tttttttttttttttttttttttt
> t
> t
> t
> R3 tttttttttt------------
> t
> t
> t
> R2-tttttttt--------------
>
>
> Joel
>
> -----Original Message-----
> From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
> Sent: Friday, April 27, 2007 11:36 AM
> To: Chris.Fouts@qimonda.com; users@subversion.tigris.org
> Subject: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
> > 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)
>
> Don't understand. There isn't an RN-main and a RN-branch.
> There is only one branch for each of R1, R2, R3, etc.
>
> >
> > Like I said it does NOT matter what you call it, you still have a
> > trunk.
>
> There is nothing in the second scheme like trunk in the first
> scheme. Say, for illustration purposes, you always have three
> releases going concurrently. When the the oldest release is
> retired, a new one starts. So, the first three-release
> situation is as shown below.
>
>
> Scheme 1 (SVN Standard):
>
> Each release starts on the trunk and *moves* to a release
> branch when the next release started.
>
>
>
> R1
> /-----------------------
> /
> /
> / R2
> / /----------------
> / /
> / /
> / /
> R1 / R2 / R3
> Trunk--------/--------------------------------------------
>
>
> Scheme 2 (Homogenous Release Branches)
>
> Each release starts on a branch and *stays* on the branch
> until it is retired. Each new release RN branches off of RN-1
> (not the trunk).
>
>
>
> R3 /----------------------
> /
> /
> /
> R2 /---------------------
> /
> /
> /
> R1-----------------------
>
>
>
> Now say that you retire R1 and start R4. The new situation looks like:
>
>
> R2
> /----------------
> /
> / R3
> / /------------------
> / /
> / /
> R2 / R3 / R4
> Trunk----------------------------------------------------
>
> The R1 release branch was retired (and deleted from the
> repository). R3 was moved to a release branch. R4 now lives
> on the trunk.
>
>
> Scheme 2 (Homogenous Release Branches)
>
> Each release starts on a branch and *stays* on the branch
> until it is retired. Each new release RN branches off of RN-1.
>
>
>
> R4 /----------------------
> /
> /
> /
> R3 /---------------------
> /
> /
> /
> R2-----------------------
>
> The original R1 branch was deleted from the repository. R3
> stays on its original branch. R4 starts (and will stay until
> retirement) on a branch taken from R3 (and not from the trunk).
>
> The point is, for the 1st scheme, all releases start the trunk and
> *move* to a release branch. The trunk exists for the life of
> the application. In the second scheme, each release stays on
> it's original branch until the release is retired. And, there
> is no *trunk* branch
> (dir) that lives for the life of the application.
>
> If anyone is still with me at this point, my purpose isn't
> really to say that the second scheme is *better*. I was just
> trying to see if anyone could see any problems with using it.
> So far, we've done quite a bit of experimentation and can see
> no problems. But... Being new to SVN, there are lots of folks
> that have more insight than us.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
> -----Original Message-----
> From: Redman, Joel L [mailto:joel.redman@siemens.com]
> Sent: Friday, April 27, 2007 10:48 AM
> To: Irvine, Chuck R [EQ]
> Cc: users@subversion.tigris.org
> Subject: RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
> IMHO, the trunk shows how your project has changed over time,
> release is snapshots which should never be modified
> thereafter, barring horrible horrible bugs, and branch is
> active changes, which may or may not be complete and ready to
> merge into trunk. That concept gets lost without a trunk.
> Conceptually Scheme 2 says that each release is equal and
> equally likely to be modified.
That is probably the crucial point. Like it or not (and I don't) where I
work there will often be multiple releases in development concurrently.
Two in active development and one in production is fairly common.
>
> Otherwise, your trunk is implicit, starting from ground 0 and
> following each line up. Depends on what you want to track I
> suppose, or at least where you want to track it.
>
>
> R4 tttttttttttttttttttttttt
> t
> t
> t
> R3 tttttttttt------------
> t
> t
> t
> R2-tttttttt--------------
>
>
> Joel
>
> -----Original Message-----
> From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
> Sent: Friday, April 27, 2007 11:36 AM
> To: Chris.Fouts@qimonda.com; users@subversion.tigris.org
> Subject: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
> > 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)
>
> Don't understand. There isn't an RN-main and a RN-branch.
> There is only one branch for each of R1, R2, R3, etc.
>
> >
> > Like I said it does NOT matter what you call it, you still have a
> > trunk.
>
> There is nothing in the second scheme like trunk in the first
> scheme. Say, for illustration purposes, you always have three
> releases going concurrently. When the the oldest release is
> retired, a new one starts. So, the first three-release
> situation is as shown below.
>
>
> Scheme 1 (SVN Standard):
>
> Each release starts on the trunk and *moves* to a release
> branch when the next release started.
>
>
>
> R1
> /-----------------------
> /
> /
> / R2
> / /----------------
> / /
> / /
> / /
> R1 / R2 / R3
> Trunk--------/--------------------------------------------
>
>
> Scheme 2 (Homogenous Release Branches)
>
> Each release starts on a branch and *stays* on the branch
> until it is retired. Each new release RN branches off of RN-1
> (not the trunk).
>
>
>
> R3 /----------------------
> /
> /
> /
> R2 /---------------------
> /
> /
> /
> R1-----------------------
>
>
>
> Now say that you retire R1 and start R4. The new situation looks like:
>
>
> R2
> /----------------
> /
> / R3
> / /------------------
> / /
> / /
> R2 / R3 / R4
> Trunk----------------------------------------------------
>
> The R1 release branch was retired (and deleted from the
> repository). R3 was moved to a release branch. R4 now lives
> on the trunk.
>
>
> Scheme 2 (Homogenous Release Branches)
>
> Each release starts on a branch and *stays* on the branch
> until it is retired. Each new release RN branches off of RN-1.
>
>
>
> R4 /----------------------
> /
> /
> /
> R3 /---------------------
> /
> /
> /
> R2-----------------------
>
> The original R1 branch was deleted from the repository. R3
> stays on its original branch. R4 starts (and will stay until
> retirement) on a branch taken from R3 (and not from the trunk).
>
> The point is, for the 1st scheme, all releases start the trunk and
> *move* to a release branch. The trunk exists for the life of
> the application. In the second scheme, each release stays on
> it's original branch until the release is retired. And, there
> is no *trunk* branch
> (dir) that lives for the life of the application.
>
> If anyone is still with me at this point, my purpose isn't
> really to say that the second scheme is *better*. I was just
> trying to see if anyone could see any problems with using it.
> So far, we've done quite a bit of experimentation and can see
> no problems. But... Being new to SVN, there are lots of folks
> that have more insight than us.
>
> 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
RE: RE: RE: RE: Re: Why have a trunk dir, anyway?!
Posted by "Redman, Joel L" <jo...@siemens.com>.
IMHO, the trunk shows how your project has changed over time, release is
snapshots which should never be modified thereafter, barring horrible
horrible bugs, and branch is active changes, which may or may not be
complete and ready to merge into trunk. That concept gets lost without
a trunk. Conceptually Scheme 2 says that each release is equal and
equally likely to be modified.
Otherwise, your trunk is implicit, starting from ground 0 and following
each line up. Depends on what you want to track I suppose, or at least
where you want to track it.
R4 tttttttttttttttttttttttt
t
t
t
R3 tttttttttt------------
t
t
t
R2-tttttttt--------------
Joel
-----Original Message-----
From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
Sent: Friday, April 27, 2007 11:36 AM
To: Chris.Fouts@qimonda.com; users@subversion.tigris.org
Subject: RE: RE: RE: Re: Why have a trunk dir, anyway?!
> 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)
Don't understand. There isn't an RN-main and a RN-branch. There is only
one branch for each of R1, R2, R3, etc.
>
> Like I said it does NOT matter what you call it, you still
> have a trunk.
There is nothing in the second scheme like trunk in the first scheme.
Say, for illustration purposes, you always have three releases going
concurrently. When the the oldest release is retired, a new one starts.
So, the first three-release situation is as shown below.
Scheme 1 (SVN Standard):
Each release starts on the trunk and *moves* to a release branch when
the next release started.
R1
/-----------------------
/
/
/ R2
/ /----------------
/ /
/ /
/ /
R1 / R2 / R3
Trunk--------/--------------------------------------------
Scheme 2 (Homogenous Release Branches)
Each release starts on a branch and *stays* on the branch until it is
retired. Each new release RN branches off of RN-1 (not the trunk).
R3 /----------------------
/
/
/
R2 /---------------------
/
/
/
R1-----------------------
Now say that you retire R1 and start R4. The new situation looks like:
R2
/----------------
/
/ R3
/ /------------------
/ /
/ /
R2 / R3 / R4
Trunk----------------------------------------------------
The R1 release branch was retired (and deleted from the repository). R3
was moved to a release branch. R4 now lives on the trunk.
Scheme 2 (Homogenous Release Branches)
Each release starts on a branch and *stays* on the branch until it is
retired. Each new release RN branches off of RN-1.
R4 /----------------------
/
/
/
R3 /---------------------
/
/
/
R2-----------------------
The original R1 branch was deleted from the repository. R3 stays on its
original branch. R4 starts (and will stay until retirement) on a branch
taken from R3 (and not from the trunk).
The point is, for the 1st scheme, all releases start the trunk and
*move* to a release branch. The trunk exists for the life of the
application. In the second scheme, each release stays on it's original
branch until the release is retired. And, there is no *trunk* branch
(dir) that lives for the life of the application.
If anyone is still with me at this point, my purpose isn't really to say
that the second scheme is *better*. I was just trying to see if anyone
could see any problems with using it. So far, we've done quite a bit of
experimentation and can see no problems. But... Being new to SVN, there
are lots of folks that have more insight than us.
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
RE: RE: RE: Re: Why have a trunk dir, anyway?!
Posted by Ch...@qimonda.com.
Sorry, I mixed this with another thread; please ignore
what I said...
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Friday, April 27, 2007 11:36 AM
>To: Fouts Christopher (QNA RTP PT PREV); users@subversion.tigris.org
>Subject: RE: RE: RE: Re: Why have a trunk dir, anyway?!
>
>
>> 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)
>
>Don't understand. There isn't an RN-main and a RN-branch.
>There is only one branch for each of R1, R2, R3, etc.
>
>>
>> Like I said it does NOT matter what you call it, you still have a
>> trunk.
>
>There is nothing in the second scheme like trunk in the first scheme.
>Say, for illustration purposes, you always have three releases
>going concurrently. When the the oldest release is retired, a
>new one starts.
>So, the first three-release situation is as shown below.
>
>
>Scheme 1 (SVN Standard):
>
>Each release starts on the trunk and *moves* to a release
>branch when the next release started.
>
>
>
> R1
> /-----------------------
> /
> /
> / R2
> / /----------------
> / /
> / /
> / /
> R1 / R2 / R3
>Trunk--------/--------------------------------------------
>
>
>Scheme 2 (Homogenous Release Branches)
>
>Each release starts on a branch and *stays* on the branch
>until it is retired. Each new release RN branches off of RN-1
>(not the trunk).
>
>
>
> R3 /----------------------
> /
> /
> /
> R2 /---------------------
> /
> /
> /
>R1-----------------------
>
>
>
>Now say that you retire R1 and start R4. The new situation looks like:
>
>
> R2
> /----------------
> /
> / R3
> / /------------------
> / /
> / /
> R2 / R3 / R4
>Trunk----------------------------------------------------
>
>The R1 release branch was retired (and deleted from the
>repository). R3 was moved to a release branch. R4 now lives on
>the trunk.
>
>
>Scheme 2 (Homogenous Release Branches)
>
>Each release starts on a branch and *stays* on the branch
>until it is retired. Each new release RN branches off of RN-1.
>
>
>
> R4 /----------------------
> /
> /
> /
> R3 /---------------------
> /
> /
> /
>R2-----------------------
>
>The original R1 branch was deleted from the repository. R3
>stays on its original branch. R4 starts (and will stay until
>retirement) on a branch taken from R3 (and not from the trunk).
>
>The point is, for the 1st scheme, all releases start the trunk and
>*move* to a release branch. The trunk exists for the life of
>the application. In the second scheme, each release stays on
>it's original branch until the release is retired. And, there
>is no *trunk* branch
>(dir) that lives for the life of the application.
>
>If anyone is still with me at this point, my purpose isn't
>really to say that the second scheme is *better*. I was just
>trying to see if anyone could see any problems with using it.
>So far, we've done quite a bit of experimentation and can see
>no problems. But... Being new to SVN, there are lots of folks
>that have more insight than us.
>
>Thanks!
>
>Chuck
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: RE: Re: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
> 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)
Don't understand. There isn't an RN-main and a RN-branch. There is only
one branch for each of R1, R2, R3, etc.
>
> Like I said it does NOT matter what you call it, you still
> have a trunk.
There is nothing in the second scheme like trunk in the first scheme.
Say, for illustration purposes, you always have three releases going
concurrently. When the the oldest release is retired, a new one starts.
So, the first three-release situation is as shown below.
Scheme 1 (SVN Standard):
Each release starts on the trunk and *moves* to a release branch when
the next release started.
R1
/-----------------------
/
/
/ R2
/ /----------------
/ /
/ /
/ /
R1 / R2 / R3
Trunk--------/--------------------------------------------
Scheme 2 (Homogenous Release Branches)
Each release starts on a branch and *stays* on the branch until it is
retired. Each new release RN branches off of RN-1 (not the trunk).
R3 /----------------------
/
/
/
R2 /---------------------
/
/
/
R1-----------------------
Now say that you retire R1 and start R4. The new situation looks like:
R2
/----------------
/
/ R3
/ /------------------
/ /
/ /
R2 / R3 / R4
Trunk----------------------------------------------------
The R1 release branch was retired (and deleted from the repository). R3
was moved to a release branch. R4 now lives on the trunk.
Scheme 2 (Homogenous Release Branches)
Each release starts on a branch and *stays* on the branch until it is
retired. Each new release RN branches off of RN-1.
R4 /----------------------
/
/
/
R3 /---------------------
/
/
/
R2-----------------------
The original R1 branch was deleted from the repository. R3 stays on its
original branch. R4 starts (and will stay until retirement) on a branch
taken from R3 (and not from the trunk).
The point is, for the 1st scheme, all releases start the trunk and
*move* to a release branch. The trunk exists for the life of the
application. In the second scheme, each release stays on it's original
branch until the release is retired. And, there is no *trunk* branch
(dir) that lives for the life of the application.
If anyone is still with me at this point, my purpose isn't really to say
that the second scheme is *better*. I was just trying to see if anyone
could see any problems with using it. So far, we've done quite a bit of
experimentation and can see no problems. But... Being new to SVN, there
are lots of folks that have more insight than us.
Thanks!
Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: Re: Why have a trunk dir, anyway?!
Posted by Ch...@qimonda.com.
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
>> <Ch...@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
RE: RE: Re: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
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
> <Ch...@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
RE: Re: Why have a trunk dir, anyway?!
Posted by Ch...@qimonda.com.
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 <Ch...@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
RE: Re: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
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 <Ch...@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
Re: Why have a trunk dir, anyway?!
Posted by Josh Gilkerson <jw...@google.com>.
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 <Ch...@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
RE: RE: Why have a trunk dir, anyway?!
Posted by Ch...@qimonda.com.
Is the Release just your trunk? I assumed (perhaps the fallacy
of my logic) that RN was based (branched) from RN-1...
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Thursday, April 26, 2007 2:57 PM
>To: Fouts Christopher (QNA RTP PT PREV); users@subversion.tigris.org
>Subject: RE: RE: Why have a trunk dir, anyway?!
>
>Sorry, I'm not sure I understand? Perhaps, you're saying that
>the structure that I propose really does have a trunk and that
>I'm just giving it another name? I so, I don't think so. But,
>I don't want to assume that I know what you are referring to.
>Interested to hear your reply.
>
>> -----Original Message-----
>> From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
>> Sent: Thursday, April 26, 2007 1:50 PM
>> To: users@subversion.tigris.org
>> Subject: RE: Why have a trunk dir, anyway?!
>>
>>
>> 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
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Why have a trunk dir, anyway?!
Posted by Steve Bakke <st...@amd.com>.
Effectively you are arguing to have the branches act as multiple trunks. At
least that's the way I look at it. In my view, it depends on how you'd like
to produce/maintain releases.
-steve
On 4/26/07 2:57 PM, "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>
wrote:
> Sorry, I'm not sure I understand? Perhaps, you're saying that the
> structure that I propose really does have a trunk and that I'm just
> giving it another name? I so, I don't think so. But, I don't want to
> assume that I know what you are referring to. Interested to hear your
> reply.
>
>> -----Original Message-----
>> From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
>> Sent: Thursday, April 26, 2007 1:50 PM
>> To: users@subversion.tigris.org
>> Subject: RE: Why have a trunk dir, anyway?!
>>
>>
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
RE: RE: Why have a trunk dir, anyway?!
Posted by "Irvine, Chuck R [EQ]" <Ch...@Embarq.com>.
Sorry, I'm not sure I understand? Perhaps, you're saying that the
structure that I propose really does have a trunk and that I'm just
giving it another name? I so, I don't think so. But, I don't want to
assume that I know what you are referring to. Interested to hear your
reply.
> -----Original Message-----
> From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
> Sent: Thursday, April 26, 2007 1:50 PM
> To: users@subversion.tigris.org
> Subject: RE: Why have a trunk dir, anyway?!
>
>
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Why have a trunk dir, anyway?!
Posted by Ch...@qimonda.com.
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
RE: Why have a trunk dir, anyway?!
Posted by "Brown, Carlton" <Ca...@BellSouth.com>.
The branch pattern you have described here is called a continual
cascade. The nature and pitfalls of it are described here, part of a
document that is well worth a read:
http://www.cmcrossroads.com/bradapp/acme/branching/pitfalls.html#Continu
alCascading
Long story short... continual cascade is OK for projects where the whole
team is all working on the next release together at the same time. It
begins to fall apart when you have R5 and R6 due at different dates in
the future, but must begin work in parallel because R6 will take a lot
longer than R5.
-----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
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org