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