cvs merge confusion

[Mike Fourier]

I've been using CVS for 6 years now, but in all that time, I've never had to (or just never did) do any branching and merging. And I'm a bit confused about the 'merging'.

I've been reading O'Reilly's "Essential CVS" by Vesperman and also "the cederqvist" and I think I've turned myself around somewhere along the way.

in the o'reilly book, it says in Chapter 10, command reference ,for "update" regarding the -j switch:

if two -j options are used, determine the changes between the first -j revision and the second -j revision and merge those changes to the sandbox.

Then, in the cederqvist, section 5.7 "Merging from a branch several times" it says:

... you need to specify that you only want to merge the changes on the branch which have not yet been merged into the trunk. To do that you specify two '-j' options, and CVS merges the changes from the first revision to the second revision.

So... from these two samples, what I *think* it means is this:

"pick the two tags on the *branch* you wish to find the differences between. Then take that set of differences (from tag 1, to tag 2) and apply that diff to your working copy (which you would ensure is 'trunk'). "

ie: They are *not* saying "it merges *from* branch_tag_1 *to* trunk_tag_2". They are saying "it merges the difference between branch_tag_1 and branch_tag_2, *to* trunk".

Yes or no?


(I will be trying this out as well, but thought I'd ask for clarification from anyone that's been in the same spot as me).

[Ernest Friedman-Hill]

Yes, your interpretation is right.

... but ...

Any time I've ever tried to do multiple merges like this, it's been a mess. My experience is that it generally only succeeds in very limited cases. Avoid it if you can.

[Mike Fourier]

thanks Ernest,

If I could ask for a clarification:

Any time I've ever tried to do multiple merges like this, it's been a mess

Did you mean "Any time I've ever tried to do this (multiple merges), it's been a mess"

or did you mean to suggest there was some other way (other than "... like this...") to do multiple merges from branch to trunk, that works 'better'?


I think what compounded my initial confusion, was that I was reading the 'bible' here at my new job, and it describes tagging *trunk* with a "after_last_merge" tag, and then using it, and the branch name (effectively, branch "HEAD") for the two 'j' parameters. And so I thought for sure *that* was correct ,and somehow I was misreading the cederqvist et al.

Wow... I will definitely be testing this tomorrow.

I wonder how they (my new job) hasn't been screwing up all this time. Maybe it's something they've rarely (or ever?) done in reality. We do the "junk in the trunk" style, so each time we cut a release, it's tagged and branched off right then, in case patches are required, or UAT turns up something.

Maybe they've always just done the "easier" thing of manually committing fixes on both trunk and branch, and haven't really done merging. Or... perhaps they've done merging when "it didn't matter you did that wrong, because there were no changes on trunk...". Odd


thanks for your help.

[Ilja Preuss]

Originally posted by Ernest Friedman-Hill:

Any time I've ever tried to do multiple merges like this, it's been a mess. My experience is that it generally only succeeds in very limited cases. Avoid it if you can.

Mhh, that's interesting. In my experience, multiple merges are not a problem at all. Well, at least not a bigger problem than doing one big merge at the end.