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