[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Sander
Subject: Re: branch merging tactics (lock repository or not?)
Date: Thu, 28 Feb 2002 14:22:13 -0800

In other words, others have committed to your target branch before you
finished resolving conflicts and committed your work, right?

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.

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

>--- 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]