[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Hyslop
Subject: Re: How should one maintain a branch for development of a major feature?
Date: Thu, 06 Oct 2005 23:08:23 -0400
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]