Quoting Mark Phippard <markphip_at_gmail.com>:
> 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.
but will that first pass/merge have been applied, even if the second
pass/merge fails because of a conflict?
rday
---------------------------------------------------------------------
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 20:00:56 CEST