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

[Paul Sander]

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