Pierre, Thanks for the response.
The root of the problem seems to be these phony conflicts. I've only done a merge once (our release guy usually does them) and it is painful. I guess that is why he wants to avoid the phony conflicts. At a previous job we used ClearCase (very different model from CVS) and didn't have these phony confilcts, so I expected that CVS would have some way to avoid them as well. Thanks anyway. -- Bobman On Sat, Jan 31, 2009 at 1:48 PM, Pierre Asselin <[email protected]>wrote: > Bob Paige <[email protected]> wrote: > > > [ ... ] > > > Active development takes place on the trunk (mainline, whatever you want > to > > call it). When we are close to a release, we branch. This is a defensive > > branch to protect the release from continuing development. Once the > release > > goes out (with only minor fixes specific to the release) we merge that > back > > to the trunk. > > And you plant a moving tag at the end of the release branch, so if more > bugs get fixed later you can merge them from where you left off. Right ? > > > All well and good. > > Yes. > > > > BUT, suppose I make a change in the branch that I also need in the trunk > to > > support continuing development? > > So a bugfix on the release branch needs to be merged to the trunk, > whereas a missing feature added late to the release branch needs > to be merged to the trunk. Uh, what's the difference, and why > would you treat the two cases differently ? > > > > Simple example: I make the same change in a > > file in the branch and in the trunk. > > You mean manually on both sides ? Why ? > > > When we do the merge later, WinCVS > > throws up its hands and doesn't know how to merge the changes. > > Don't know about WinCVS, but I expect it shows you a phony conflict > with identical changes on both sides. Clean up the conflict markers > and move on ? > > > > This is a major sore point for our release guy as it adds many manual > steps > > during the merge. > > > Is there some way we can do a merge and have WinCVS understand that the > same > > changes were made in both the branch and the trunk? > > Probably not. On *nix I notice fewer of these bogus conflicts, > but if they occur I clean them up and move on. I also try not to > merge the same changes twice if I can help it (leave a tag on the > branch after every merge). > > In your case, there seems to be no reason to put changes on the > release branch that don't get merged into the trunk. If you start > cherry-picking you'll create work for yourself. If I ever had a > release change that I don't want on the trunk, I would probably > merge it anyway and immediately back it out, just to keep the > bookkeping simple. > > > -- > pa at panix dot com >
