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 [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] > -- [EMAIL PROTECTED] V-Net: 622-3286 Phone: 1-719-535-3286 Pager: 1-800-724-3624 # 140-1311 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs