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