[Top][All Lists]
[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!
- How should one maintain a branch for development of a major feature?,
Douglas Wade Needham <=