> -----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
Received on Fri Apr 27 17:53:06 2007