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
Received on Thu Apr 26 20:58:00 2007