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 [EMAIL PROTECTED] >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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
