[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: merge question
Re: merge question
Sat, 31 Jan 2009 22:51:51 -0500
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.
On Sat, Jan 31, 2009 at 1:48 PM, Pierre Asselin <address@hidden>
Bob Paige <address@hidden> wrote:
> [ ... ]
And you plant a moving tag at the end of the release branch, so if more
> 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.
bugs get fixed later you can merge them from where you left off. Right ?
> All well and good.
So a bugfix on the release branch needs to be merged to the trunk,
> BUT, suppose I make a change in the branch that I also need in the trunk to
> support continuing development?
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 ?
You mean manually on both sides ? Why ?
> Simple example: I make the same change in a
> file in the branch and in the trunk.
Don't know about WinCVS, but I expect it shows you a phony conflict
> When we do the merge later, WinCVS
> throws up its hands and doesn't know how to merge the changes.
with identical changes on both sides. Clean up the conflict markers
and move on ?
Probably not. On *nix I notice fewer of these bogus conflicts,
> 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?
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
pa at panix dot com