In that case, commit your first merge to a new branch and repeat the process until you get in.
>--- Forwarded mail from [EMAIL PROTECTED] >On Thu, Feb 28, 2002 at 02:22:13PM -0800, Paul Sander wrote: >> In other words, others have committed to your target branch before you >> finished resolving conflicts and committed your work, right? >> >Yes. >> What exactly do you want to do in that situation? Do you want to update >> to the top of the branch before committing, or do you want to commit first? >> You can't commit without being up to date, which means either updating or >> branching again. The method you choose depends on the perceived risk of >> lost work while performing the second update, and the likelihood of still >> more commits during the second update. >I think I want to "commit first". Some are uncomfortable with the >merge process and having a "before" and "after" set of merge tags, we >can back out of any merge and see if it was the merge that caused some >problem, or just normal commits that are causing the problem. (We >want our cake too). >> This raises the issue of a race condition that is inherent in the >> concurrent development model, where you may have to ask your colleagues >> to hold their breath long enough for you to catch up and commit your >> work. >Yes, this was my thinking. >> >--- Forwarded mail from [EMAIL PROTECTED] >> >> >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] >> >> >--- End of forwarded message from [EMAIL PROTECTED] >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
