You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Robert P. J. Day" <rp...@crashcourse.ca> on 2008/09/16 17:51:25 UTC
what happens when a "multi-part" merge has a conflict?
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?
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: what happens when a "multi-part" merge has a conflict?
Posted by "Robert P. J. Day" <rp...@crashcourse.ca>.
Quoting Mark Phippard <ma...@gmail.com>:
> On Tue, Sep 16, 2008 at 2:00 PM, Robert P. J. Day
> <rp...@crashcourse.ca> wrote:
>> Quoting Mark Phippard <ma...@gmail.com>:
>>
>>> On Tue, Sep 16, 2008 at 1:51 PM, Robert P. J. Day <rp...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: what happens when a "multi-part" merge has a conflict?
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 16, 2008 at 2:00 PM, Robert P. J. Day <rp...@crashcourse.ca> wrote:
> Quoting Mark Phippard <ma...@gmail.com>:
>
>> On Tue, Sep 16, 2008 at 1:51 PM, Robert P. J. Day <rp...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: what happens when a "multi-part" merge has a conflict?
Posted by "Robert P. J. Day" <rp...@crashcourse.ca>.
Quoting Mark Phippard <ma...@gmail.com>:
> On Tue, Sep 16, 2008 at 1:51 PM, Robert P. J. Day
> <rp...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: what happens when a "multi-part" merge has a conflict?
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Sep 16, 2008 at 1:51 PM, Robert P. J. Day <rp...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org