[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "multi-part" merge with conflicts does not "bail out with an error message"

From: Brazhnik <brazhnik_at_gmail.com>
Date: Fri, 14 Nov 2008 18:00:05 +0300

Hi
This issue is very important for me.

Is it a bug or expected behaviour?

If it is a bug I will email to dev_at_subversion.tigris.org

Thanks

On Wed, Nov 12, 2008 at 8:11 PM, Brazhnik <brazhnik_at_gmail.com> wrote:

> Hello.
>
> 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."
>
> but the svn 1.5.4 continues applying second range of changes if first range
> of changes creates conflicts and conflict resolution was postponed.
> It creates in one way files like this:
> <<<<<<< .working
> <<<<<<< .working
> bbbbb
> =======
> 22222
> >>>>>>> .merge-right.r4
> =======
> 44444
> >>>>>>> .merge-right.r6
>
> in other way the conflicted file looks like usual (without nested <<<, ===,
> >>> parts) but It losts some changes.
>
> ----
> brazhnik
>
>
Received on 2008-11-14 16:00:41 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.