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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:12:09 CEST