[cvsnt] newbie branch/merge question

[Gerhard Fiedler]

Nick Duane wrote:

> Let me add a bit more complexity to this before letting this post rest in 
> peace.  I have also made some changes to 3.7.2 centered around cleaning up 
> the build.  Ideally I would like these changes applied to a 3.7.2 build in 
> CVS (maybe called 3.7.2.5) so that I can get back to it later.  For sure I 
> need these changes applied to the current 3.8 code base.  So with that being 
> said would the following be reasonable?
> 
> * Add current 3.7.2 code to CVS
> * Tag as 3.7.2
> * Create 3.7.2 branch at 3.7.2 tag

So far sounds good.

> * Apply my changes to trunk
> * Tag as 3.7.2.5

I'm not sure this is what you meant. If you apply your 3.7.2.5 changes to
the trunk (HEAD), why did you create a 3.7.2 branch above? This 3.7.2
branch would usually be where further improvements to that version would
go; that's the purpose of the branch. So maybe you think about applying
these changes to the 3.7.2 branch, then merge them back to the trunk (which
should be straightforward without conflicts, as no conflicting changes
happened on the trunk).

One reason for this is that you may find some more things that you want to
fix on that 3.7.2 version. Where would you put that if you have the 3.7.2.5
version on the trunk rather than on the 3.7.2 branch? Following that some
reasoning, the 3.7.2.5 code would be tagged on the branch, not on the
trunk.

> * Create 3.7.3 branch from 3.7.2 tag
> * Copy 3.7.3 code to 3.7.3 branch
> * Merge 3.7.3 into trunk
> * Tag as 3.7.3.5

This tag (if I understand you correctly on the trunk) looks strange. For
me, all tags related to the 3.7.3 release should be tagging code on the
3.7.3 branch. The code on the trunk after the merge does not exist in that
version on the 3.7.3 branch -- which is where /all/ 3.7.3 code is supposed
to be. So having a 3.7.3.? tag that's not on the 3.7.3 branch is extremely
confusing.

If you want to have your 3.7.2.5 changes in the 3.7.3 branch, you need to
merge them there. You don't do that with your procedure.

> * Create 3.8 branch from 3.7.2 tag
> * Merge trunk into 3.8 branch

Not good. Starts bi-directional merging, as later you will want to merge
your 3.8 development back to the trunk. 

The question here is why you want to have a 3.8 branch. You only need a
branch when you actually "branch"; that is, when you have two lines of
development that separate. What would be on HEAD after the 3.8 branch?

It seems to me that 3.8 is your current most advanced line of development.
Unless there is another, more advanced line of development, that's probably
quite fine on HEAD.


> By the way, my changes consists of several renamed directories and files 
> (copy and delete) as well as other changes.  Not sure how well 
> directory/file renames merge.

They are basically a combination of remove/add. This doesn't merge well.
That is, the remove/add itself merges fine, but it doesn't consider any
changes between the removed and the added file.

Say you have file A on the trunk. You branch it, and on the branch you
"rename" it to file B (that is, you remove file A and add file B). Then you
make some changes to file B. In the meanwhile, on the trunk, you make some
changes to file A. Now you merge the branch into the trunk.

It will detect that file A has been removed and file B has been added, and
that's what it will do to the trunk. It will /not/ merge the changes you
made to file A on the trunk with the changes you made to file B on the
branch, as it really can't know that they are the same file. This is
something you have to do manually, using 3-way comparison tools and a lot
of attention to catch all these cases :) 

Gerhard