info-cvs
[Top][All Lists]
Advanced

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

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


From: Douglas Wade Needham
Subject: How should one maintain a branch for development of a major feature?
Date: Thu, 6 Oct 2005 13:27:36 -0400
User-agent: Mutt/1.4.2.1i

Greetings everyone,

I have a question regarding branches.  At my employer, we have a major
new feature which is going to take some considerable effort and time
(potentially several developer weeks or months), but will create
significant instability which already undergoes significant change.
>From previous experience of working with CVS and branches, I know we
can create a branch to help us reduce the instability.  As a result,
we are doing something like the following:

    cvs co module
    cd module
    cvs tag feature_branch_base
    cvs tag -b feature_branch

Now, as mentioned, this feature will take some time complete, and will
eventually depend on smaller changes/features which will continue to
be found on the mainline.  So we will want to merge the mainline
changes into the branch from time to time, and perhaps from time to
time (if things are stable), merging the branch back to the mainline.
Of course, eventually we will want to merge everything back to
the mainline when the feature is complete.  

>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


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?

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?

   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.

Any input or additional insight would be greatly appreciated.

Thanks!

- Doug

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter! 




reply via email to

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