Re: branch merging tactics (lock repository or not?)

[David Everly]

How do I commit a large number of changes (generated by a merge) to
the branch I'm merging to when there are several commits to that
branch while I'm in the process of merging?  And if I do update before
commiting the merge (to bring in the new changes so that I'm allowed
to check in) is there a way to have distinct "before merge" and "after
merge" tags (that do not include "during merge" commits?

On Thu, Feb 28, 2002 at 01:22:04PM -0800, Paul Sander wrote:
> What is the reason for locking the repository?  Normally, it's to avoid
> race conditions, e.g. when a commit is done on one of the branches involved
> in the merge.
> 
> You can avoid locking if you know the version numbers of the contributors
> beforehand, or can otherwise identify them uniquely (e.g. with tags or
> timestamps).  So, consider this:
> 
> Apply a tag to the top of the contributor branch before commencing the
> merge.  (I think rtag works with branch and timestamps, or you can check it
> out and apply the tag to the sandbox and then release the sandbox.)  Then
> use "cvs update" with the appropriate number of -j options to perform the
> merge, using the tagged contributors.
> 
> A second benefit to creating a contributor tag is that you can use it as
> the common ancestor tag for future 3-way merges, which reduces the number
> of conflicts you must resolve by hand.
> 
> >--- Forwarded mail from address@hidden
> 
> >We currently have 3 active development branches as well as our trunk.
> >Our trunk holds our next major release.  Branches A, B, and C hold our
> >next three major releases (in that order).  About once a week, we merge
> >the incremental changes (since the last merge) from the trunk, to branch
> >A, then from branch A to branch B, then from branch B to branch C.  We
> >also have bug fix branches for releases currently in production, and if
> >one of them has a new release on it, we merge (or consider merging)
> >these changes into the trunk.
> 
> >I have been locking the repository while we do these merges, but some
> >developers are complaining.
> 
> >Is it a good or bad practice to lock while merging branches.  If we do
> >not lock the repository while merging branches, what would be the
> >potential result?
> 
> >--- End of forwarded message from address@hidden
> 

-- 
address@hidden
V-Net:       622-3286
Phone: 1-719-535-3286
Pager: 1-800-724-3624 # 140-1311