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

[Paul Sander]

In that case, commit your first merge to a new branch and repeat the process
until you get in.

>--- Forwarded mail from address@hidden

>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 address@hidden
>> 
>> >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
>> 
>> >--- End of forwarded message from address@hidden

>--- End of forwarded message from address@hidden