FAQ
There seems to be a problem with the merge logic in SVN when merging
repeated added & deleted changes out-of-order.

Example activity on branch A:
r1: A new file is added.
r2: A line is added
r3: The line is removed
r4: The line is re-added
Later activity on branch B (created from A@r1):
r5: r2 and r4 are merged in.
r6: r3 is merged in.

What happens in r5 is that repeated merging of the same change does _not_
cause duplication or merge conflict. Instead, r4 seems to be ignored. The
end result after r6 (a complete merge) is that r4 is missing from branch B.
This is inconsistent with svn:mergeinfo which claims that it has been
merged. Patches to reproduce are attached.

Could it be possible to make svn merges fail on repeated merges of the same
change, instead of just ignoring them?

The problem was reproduced using svn 1.8.1 (command-line) client on Win7
64bit SP1, and svn server 1.7.6 (VisualSVN 2.5.6, Apache 2.2.22) on Win
server 2008 R2.

Thanks in advance,
Fredrik Orderud

Search Discussions

  • Johan Corveleyn at Aug 5, 2013 at 9:31 pm

    On Mon, Aug 5, 2013 at 4:20 PM, Fredrik Orderud wrote:
    There seems to be a problem with the merge logic in SVN when merging
    repeated added & deleted changes out-of-order.

    Example activity on branch A:
    r1: A new file is added.
    r2: A line is added
    r3: The line is removed
    r4: The line is re-added
    Later activity on branch B (created from A@r1):
    r5: r2 and r4 are merged in.
    r6: r3 is merged in.

    What happens in r5 is that repeated merging of the same change does _not_
    cause duplication or merge conflict. Instead, r4 seems to be ignored. The
    end result after r6 (a complete merge) is that r4 is missing from branch B.
    This is inconsistent with svn:mergeinfo which claims that it has been
    merged. Patches to reproduce are attached.

    Could it be possible to make svn merges fail on repeated merges of the same
    change, instead of just ignoring them?

    The problem was reproduced using svn 1.8.1 (command-line) client on Win7
    64bit SP1, and svn server 1.7.6 (VisualSVN 2.5.6, Apache 2.2.22) on Win
    server 2008 R2.
    I can't offer much real help, but ... I've read something similar before ...

    Ah, here it is:

         http://svn.haxx.se/dev/archive-2013-04/0205.shtml

    a somewhat recent thread on the dev-list. It's quite an interesting
    discussion IMO, so at least this gives you some context, and confirms
    that this is known behavior.

    --
    Johan
  • Johan Corveleyn at Aug 6, 2013 at 8:06 am
    Please use reply all to include the list. More below ...
    On 6 Aug 2013 08:48, "Fredrik Orderud" wrote:
    On Mon, Aug 5, 2013 at 11:31 PM, Johan Corveleyn wrote:
    On Mon, Aug 5, 2013 at 4:20 PM, Fredrik Orderud wrote:
    What happens in r5 is that repeated merging of the same change does
    _not_
    cause duplication or merge conflict. Instead, r4 seems to be ignored.
    The
    end result after r6 (a complete merge) is that r4 is missing from
    branch B.
    This is inconsistent with svn:mergeinfo which claims that it has been
    merged. Patches to reproduce are attached.

    Could it be possible to make svn merges fail on repeated merges of the
    same
    change, instead of just ignoring them?
    I can't offer much real help, but ... I've read something similar before
    ...
    Ah, here it is:
    http://svn.haxx.se/dev/archive-2013-04/0205.shtml

    a somewhat recent thread on the dev-list. It's quite an interesting
    discussion IMO, so at least this gives you some context, and confirms
    that this is known behavior.

    Thank you for the information Johan.

    At my employer, we have a change-approval process based on merging
    changes from trunk to a release-branch. This merging often happens
    out-of-order. This problem is really problematic for us, since we sometimes
    loose changes in the merge process, even though svn claims to have merged
    everything.
    Do you, or anyone else on this list, think it could be possible to
    register a bug report on this issue?
    >

    Yes, go ahead and file an issue, and include links to this and the other
    mail thread in the description.

    At this point, I am not sure whether I'd call it a defect or an enhancement
    request (asking for a new optional strict mode for merging), I guess it
    depends on your point of view. But it doesn't matter that much, so go with
    what you think is best.

    --
    Johan
  • Fredrik Orderud at Aug 6, 2013 at 8:55 am

    On Tue, Aug 6, 2013 at 10:05 AM, Johan Corveleyn wrote:

    Yes, go ahead and file an issue, and include links to this and the other
    mail thread in the description.

    At this point, I am not sure whether I'd call it a defect or an
    enhancement request (asking for a new optional strict mode for merging), I
    guess it depends on your point of view. But it doesn't matter that much, so
    go with what you think is best.
    Thanks! I took the liberty of categorizing it as a "defect" and registered
    http://subversion.tigris.org/issues/show_bug.cgi?id=4405

    Please let me know if there is anything else I can do to increase the
    likelihood of this issue being fixed as soon as reasonably possible.

    Best,
    Fredrik
  • Johan Corveleyn at Aug 6, 2013 at 1:53 pm

    On Tue, Aug 6, 2013 at 10:55 AM, Fredrik Orderud wrote:
    On Tue, Aug 6, 2013 at 10:05 AM, Johan Corveleyn wrote:

    Yes, go ahead and file an issue, and include links to this and the other
    mail thread in the description.

    At this point, I am not sure whether I'd call it a defect or an
    enhancement request (asking for a new optional strict mode for merging), I
    guess it depends on your point of view. But it doesn't matter that much, so
    go with what you think is best.
    Thanks! I took the liberty of categorizing it as a "defect" and registered
    http://subversion.tigris.org/issues/show_bug.cgi?id=4405

    Please let me know if there is anything else I can do to increase the
    likelihood of this issue being fixed as soon as reasonably possible.
    You filed the issue, tying the various bits of information together,
    that's a good first step.

    As you've probably seen, I also added a note about your mail-thread
    and corresponding issue to the dev-thread I talked about earlier, to
    give it some more visibility.

    Maybe someone will pick this up and start working on it. But keep in
    mind that there are a lot of issues, some of which impact a lot of
    users (and everyone has his own priorities of course).

    Some of the things you can do to get this issue forward are (a) help
    drive (or participate in) the discussion to get to the finer details
    of the desired behavior and (b) write a patch :-). Also, since you
    filed this as a "defect", it would be helpful if you wrote an XFAIL
    ("expected fail") testcase for our (python) testsuite (which can be
    used to clearly demonstrate the problem, and later as a regression
    test, when the issue gets fixed).

    If you're interested, you should probably head over to the dev@
    mailinglist for continuing the discussion. If you want to have a go at
    writing a patch (or a regression test), you should take a look at the
    community guide [1] (and of course, feel free to ask any questions
    that might come up, on the dev-list).

    [1] http://subversion.apache.org/docs/community-guide/

    Thanks,
    --
    Johan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriessubversion
postedAug 5, '13 at 2:21p
activeAug 6, '13 at 1:53p
posts5
users2
websitesubversion.apache.org
irc#svn

People

Translate

site design / logo © 2021 Grokbase