[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: what happens when a "multi-part" merge has a conflict?

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 16 Sep 2008 13:56:17 -0400

On Tue, Sep 16, 2008 at 1:51 PM, Robert P. J. Day <rpjday_at_crashcourse.ca> wrote:
> from the section "Advanced Merging," side note regarding doing a merge
> which has to jump over a single earlier, cherrypicked revision:
> "Did you notice how, in the last example, the merge invocation caused two
> distinct ranges of merges to be applied? The svn merge command applied two
> independent patches to your working copy to skip over changeset 355, which
> your branch already contained. There's nothing inherently wrong with this,
> except that it has the potential to make conflict resolution trickier. If
> the first range of changes creates conflicts, you must resolve them
> interactively for the merge process to continue and apply the second range
> of changes. If you postpone a conflict from the first wave of changes, the
> whole merge command will bail out with an error message."
> fair enough, but that doesn't explain what happens if the *first* patch
> succeeds and the *second* one runs into a conflict. or am i just reading
> that too pedantically?

Unless there is a need for a *third* pass, then there is nothing
special about the second pass. It will be a conflict, and you can
choose to resolve it interactively or wait and do it later. The point
of the passage is to point out that if you do not resolve the conflict
in the *first* pass then the merge process cannot continue to the
second pass.

Mark Phippard
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-16 19:56:39 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.