Re: merge question

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
>