RE: Nested Branches

I originally thought that we would have three simultaneous lines of
development that would force us into having the trunk and 2
sub-branches, but as I talked to some people about what changes were in
the trunk, it looks like we can ship branch 1 code out of the trunk and
branch 1.1 code out of branch 1 - if that makes sense. Anyway, I dodged
the bullet this time. Thanks for the feedback everyone.

Robert

-----Original Message-----
From: Brad Appleton [mailto:brad.appleton@gmail.com]
Sent: Friday, October 07, 2005 5:48 AM
To: Robert Cronk
Cc: users@subversion.tigris.org
Subject: Re: Nested Branches

Robert Cronk wrote:
> And now, they want to change it to this:
>
> +--------- branch 1.1
> /
> +-----+----------- branch 1 +----branch 2
> / /
> -----------+---------------------------------+----------- trunk

What is the effective difference between the above, versus branching off
the 1.1 branch *after* it has been mainlined (merged to the trunk)
instead of before.

(Am I correct in assuming that, prior to branch 2 being created, branch
1 was mainlining to the trunk anyway)?

> So that I can't just put branch 1 and branch 1.1 into the branches
directory

You could if 1.1 was mainlined to trunk prior to branching it. What
would prevent that from being possible in your situation?

Put another way -- why is it necessary for your 1.1 branch to branch off

of 1.0 instead of branch off where 1.0 got mainlined on the trunk?

The drawing you depicted suggests a "branch by release number" strategy
where one tries to make the branching structure reflect the
release-numbering scheme. If so, this is a classic pitfall, and one of
the better descriptions of it is in:
    "The Importance of Branching Models in SCM"
    [http://www.seapine.com/pub/papers/SCMBranchingModels.pdf]

They suggest that the release-numbering scheme should not dictate the
branching structure. The branching structure should be dictated by the
structure of the work projects and their work efforts.

This same "project-oriented" approach to branching structure is also
what is recommended by a number of other sources. See the
BranchingAndMerging page on www.cmwiki.com at
[http://www.seapine.com/pub/papers/SCMBranchingModels.pdf]

That said ... if you have your mind "set" on doing nested branches. It
seems to me like your issue is whether or not to make the "branches"
directory structure be "flat" or make the branching directory structure
be nested and reflect the "true" branching structure.

It would seem the only thing stopping you from making a nested branching

structure is that it not the norm for subversion usage, and many other
"normal" practices assume a flat structure in order to work? (is this
mostly correct?)

If so, I guess your problem boils down to: given a branch name, how do
you know which branch it should "mainline" (merge) to? Based on your
drawing, the branch it should merge to is the branch it was "forked"
from.

* So you could either enforce some strict naming convention and use that

to "infer" the name of the "parent" branch from the name of one of its
child "branches

* Or you could try to use properties somehow (or some text file of your
own choosing) to store the "parentage" information for your branches.

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
    Software CM Patterns (www.scmpatterns.com)
    Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org