[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merge question

From: Pierre Asselin
Subject: Re: merge question
Date: Sat, 31 Jan 2009 18:48:24 +0000 (UTC)
User-agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (NetBSD/4.0 (i386))

Bob Paige <address@hidden> 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.


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]