Nested Branches

[Robert Cronk <rc...@altiris.com>]

Recently, our company has decided to work with concurrent development in
a slightly different way than it has in the past.  In the past, we have
had the following style of branching (1 level deep):

             +-------- branch 1      +------ branch 2
            /                       /
-----------+-----------------------+---------------------- trunk

And so the branches that appear in the branches directory are siblings
and not leveled or nested or anything.  All changes made in branches are
merged directly to the trunk and are assumed to be branches of the
trunk.

And now, they want to change it to this:

                     +--------- branch 1.1
                    /
             +-----+----------- branch 1       +----branch 2
            /                                 /
-----------+---------------------------------+----------- trunk

So that I can't just put branch 1 and branch 1.1 into the branches
directory because they are nested and related so that I would want to
merge changes from branch 1.1 into branch 1 and then from branch 1 into
the trunk.  This way, the developers only have to put their changes in
one time and it will cascade merge down from the furthest out branch
toward the trunk.

I have thought of a few ways to do this.  I have thought of setting up
some kind of directory structure in the branches that would indicate
which branch came from which.  I have also thought of just trying to
figure out which branch came from which programmatically by looking at
logs, etc.

I currently don't want to make it more complex than 2 levels deep, but
if I'm going to set it up for 2 levels deep, it would seem to be just as
easy to make it generic and make it n-levels deep.

I want feedback from anyone out there that has had success in
implementing this type of structure successfully or have run into
problems with certain methods of doing it.  Please let me know what you
all think.  Of course, we'll be throwing this new structure into a live
build system within the next week or two.  ;-)

Thanks,
Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Nested Branches

[Brad Appleton <br...@gmail.com>]

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 <br...@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