Re: How should one maintain a branch for development of a major feature?

[Jim Hyslop]

Douglas Wade Needham wrote:
> Quoting Jim Hyslop (address@hidden):
>
> > Keeping the trunk and the branch in sync can get quite complicated. IMO 
> > it's not worth the effort.
> >
> > It doesn't sound like you are planning any releases between now and the 
> > time Big Feature is complete, so I would recommend doing all work on the 
> > trunk. Make sure you tag the last good release, so that you can apply 
> > any bug fixes on a "bug fix" branch if necessary.
>
>
> Thanks for the reply Jim.  I whole-heartedly agree is is complicated.
> However, the boss wants to do this, so...

So now the time to enlighten him/her ;=)

> As for releases, we actually will have at least one, and perhaps
> several "dot" releases branched from the mainline for ourselves and
> vendors between now and the time we to the release which would have
> this feature (it is actually support for a new hardware platform by
> our firmware).  But the way things are right now, we would probably be
> pulling mainline into this branch as we go along, and then probably
> pretty much a single merge back into the mainline.  But there may be
> some support for certain chips showing up on other hardware which may
> get pulled back to the trunk sooner due to other platforms using those
> chips.

Given that, my suggestion would be to make your best guess as to which 
stream of development represent the largest amount of work, and make 
that the trunk. That will minimize the amount of merging when the main 
feature is complete.

> I agree, and generally we go this route.  Indeed, we do full builds at
> least twice a day.  However, when the project consists of several
> modules, and one of them (the module in question) contains the
> firmware which supports nearly a dozen HW platforms on several
> different CPUs, some tasks, such as adding support for an entirely new
> box with new processors, bridge chips, etc. cannot really be broken
> down smaller chunks easily.  Not saying that it cannot be done, but
> the cross compiles, common code, etc. complicate things to the point
> where doing the work in a branch is viewed as being better than what
> we have had.  And this is even with most of the platform specific code
> broken off into separate files or even subdirectories.  There were a
> few times when similar support was added in the past where there was
> just enough breakage and lost productivity which has management
> wanting us to go the way of doing this next one on a branch.

OK, there was lost productivity due to inexperience or mistakes in your 
previous attempts. How will this compare to the productivity you will 
lose while you're trying to merge the two branches? Has your team 
learned from their past experience, and can they prevent the same 
problems from happening again? (You don't have to answer these questions 
- I'm just trying to give you ammunition to convince your management 
that perhaps branching is not worth the effort).

OK, back to your original questions which I didn't answer:

>>From previous experience and reviewing the section on "Branching and
> merging", I know that for the first part, it is best that I do the
> joins and tag the merge point.  But doing the merges in both
> directions adds some complexity to this.  So, if I am thinking
> correctly, this would look something like (please provide
> corrections):
>
>     cd module_main
>     cvs -q update
>     cvs -q rtag -F -r merge_to_feature last_merge_to_feature
>     cvs -q tag -F merge_to_feature
>     cd ../module_branch
>     cvs -q update -j last_merge_to_feature -j merge_to_feature
>     # Resolve any conflicts here
>     cvs -q ci -m "Merged latest changes from head"
>     cvs -q tag -F feature_merged_from_head
>     cvs -q tag -d last_merge_to_feature
>
> As for the merge from the feature branch to the mainline, I am
> figuring it would look similar, say like the following:
>
>     cd module_branch
>     cvs -q update
>     cvs -q rtag -F -r merge_from_feature last_merge_from_feature
>     cvs -q tag -F merge_from_feature
>     cd ../module_main
>     cvs -q update -j last_merge_from_feature -j merge_from_feature
>     # Resolve any conflicts here
>     cvs -q ci -m "Merged latest changes from feature_branch"
>     cvs -q tag -F merge_feature_to_head
>     cvs -q tag -d last_merge_from_feature

These look reasonable. Try it out on a test section of your repository 
to make sure it works the way you expect.

> But all of this still leaves me with the following questions:
>
> 1) Is this sort of thing really a "good thing", which others are doing
>    on occasion?
I think I answered that one already ;=)

> 2) Am I correct in my thinking that if I merge in either direction,
>    the latest merge tags in the mainline and branch should be
>    synchronized?
If you merge in both directions at the same time, then the tip of the 
branch and the HEAD will be identical (I think that's what you asked - 
if I misunderstood the question please let me know).

>
>    I am thinking that this is the case.  But I am thinking that
>    perhaps I could end up with one or two additional revisions on the
>    destination branch being specified with the '-j' option.  Either
>    that, or perhaps it means that instead of 2 tags for each of the
>    merge directions, perhaps the 4 main merge tags could be unified
>    into a single tag on the branch and mainline (say
>    "feature_merge_with_head" and "merge_with_feature"), used for
>    merges in either direction.

You could reduce it to two tags, if all your merges are from the last 
merge point to the tip of the branch/trunk.

--
Jim