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.
--
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 19:56:39 CEST