--- Paul Sander <[EMAIL PROTECTED]> wrote:
> In that case, commit your first merge to a new
> branch and repeat the process
> until you get in.
David might also be able to use the "advisory lock"
patch (formerly known as reserved checkouts) available
at SourceForge under project RCVS.
Once insta
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?
> [...]
> This raises the issue of a race condition that is inherent in the
> concurrent development
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
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
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
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 w
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. wit
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
