merge question

[Bob Paige]

At my work we have a common problem dealing with merges. I've tried google
for and discussion of our plight, so feel free to redirect me to a current
discussion if one is available.

The scenario is this:

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.

All well and good.

BUT, suppose I make a change in the branch that I also need in the trunk to
support continuing development? Simple example: I make the same change in a
file in the branch and in the trunk. When we do the merge later, WinCVS
throws up its hands and doesn't know how to merge the changes.

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?

[Pierre Asselin]

[ ... ]
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.

[Bob Paige]

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

Post by Bob Paige

[ ... ]
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

[Pierre Asselin]

[-- text/plain, encoding 7bit, charset: ISO-8859-1, 88 lines --]
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.

Hm, you must be leaving out a step. The first time you merge from
branch to trunk, you can do

cvs update -A # back to trunk
cvs update -j branch_tag

and fix conflicts, commit. The second and subsequent times, you have
to do something else to avoid reapplying those changes.

First: put a tag at the tip of the branch from which you just merged.

cvs tag -r branch_tag branch_MERGED

Later when more work has been committed to the branch and you want
to fold it into the trunk, you do something like this:

cvs update -A # back to trunk
cvs update -j branch_MERGED -j branch_tag
fix conflicts, test...
cvs commit
cvs tag -F -r branch_tag branch_MERGED

The idea is to always leave a tag behind you, here "branch_MERGED",
at the point on the branch from which you just merged. The next
time around, this allows you to use the two "-j" form of update
and merge only from the previous merge point to the new tip. You
move the "branch_MERGED" tag after each merge; the "-F" option is
necessary because the tag already exists.

CvsNT keeps track of the last merge point automatically (in the
log message, I think) but I'm not sure how to make use of it.
Unix cvs doesn't and you have to manipulate a tag yourself.

[Arthur Barrett]

Bobman,

Post by Bob Paige
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.

I've used both ClearCase and CVS and there are no significant
differences between the merging capabilities.

All the problems usually encountered by ClearCase users switching to CVS
can be easily sorted out - may I suggest you talk to your new company
not about ClearCase vs. CVS but about paying for quality software
distributions, consulting, training, support and not paying for quality
software distributions, consulting, training, support...

Merging with WinCVS should be extremely easy, so mentioning that it is
painful indicates that you've probably got some fundamental problems.
This is not really the correct forum for discussing WinCVS - WinCVS has
it's own forum on yahoogroups - go to the winCVS web site to find the
link. It's a little complex since you are probably using WinCVS GUI,
CVS server and CVSNT client (it ships with WinCVS by default) - so
finding which component (if any) is acting up is rather complex.

And finally - there are many features of WinCVS that only work with
CVSNT (eg: merge tracking, automatic merge points, merging changesets
etc etc) so using a CVSNT server (yes it is free/GPL just like CVS, yes
it runs on linux just like CVS) is probably going to improve some of
these bugbears (but of course you should test and preferably get some
expert help and training).

Regards,


Arthur Barrett