[cvsnt] Merging branch with identical versions still changes
John Peacock
jpeacock at rowman.com
Fri Nov 7 10:32:02 GMT 2003
Glen Starrett wrote:
> But the easiest way to get a non-trivial merge to merge in cleanly is to do
> as I've outlined, I think. Do you now of a better way? I would think that
> with the method you're proposing the dev would be manually merging code
> changes into the dev branch instead of CVS automatically merging most of the
> updates + a little manual conflict resolution, which seems like a lot more
> trouble.
I'm still not making myself clear then. CVS's conflict merging is used in my
proposal, just as it is in yours. The only manual processing is the [possibly
inevitable] manual conflict resolution, which you'd have to do anyway. In fact,
with your merge trunk -> branch and branch -> trunk, there is the possibility of
two manual conflicts (unless the trunk is frozen during this process).
Rather than abstract someone else's work, I urge you to study this section:
http://cvsbook.red-bean.com/cvsbook.html#Going_Out_On_A_Limb__How_To_Work_With_Branches_And_Survive_
of the very well written "Open Source Development with CVS" by Karl Vogel (now a
core Subversion developer) and Moshe Bar. I personally prefer the "Flying Fish"
model which they discuss in some detail, whereas you are using a modified
"Dovetail" approach. It depends completely on how independent your development
is and how many people are working on each branch (I have a small shop).
NOTE: with CVSNT's mergepoint handling, all of the discussion about merging
repeatedly with the trunk is moot. You pretty much can merge in either
direction without worrying about trying to merge already applied changes.
As long as your developers are frequently doing a 'cvs update -j HEAD' on their
branch, and cleaning up any conflicts, then it is very unlikely that any
conflicts (either textual or semantic) will occur when their branch is merged
back to the trunk. It just seems to me like you are waiting to do that until
the last moment (when you are ready to merge the branch).
There is more than one to do this process. I guess I am saying your process is
OK, but you are not doing it often enough. You shouldn't wait until you are
ready to merge the branch into the trunk to find out whether the trunk changes
are going to break your code.
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
More information about the cvsnt
mailing list