Quoting Mark Phippard <markphip_at_gmail.com>:
> On Tue, Sep 16, 2008 at 2:00 PM, Robert P. J. Day
> <rpjday_at_crashcourse.ca> wrote:
>> 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?
>
> Yes. But to clarify, the second pass does not fail. All of its
> changes are also applied. It simply ends with conflicts. No
> different than a single-pass merge that ends with conflicts.
ah, gotcha, thanks.
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:13:05 CEST