From users-return-28491-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Fri Feb 7 06:52:32 2020 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by minotaur.apache.org (Postfix) with SMTP id 5158B19890 for ; Fri, 7 Feb 2020 06:52:32 +0000 (UTC) Received: (qmail 75078 invoked by uid 500); 7 Feb 2020 06:52:31 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 75058 invoked by uid 500); 7 Feb 2020 06:52:31 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 75046 invoked by uid 99); 7 Feb 2020 06:52:30 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Feb 2020 06:52:30 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 16B9A18137D for ; Fri, 7 Feb 2020 06:52:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=hammant.org Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id zsERlotcdh3e for ; Fri, 7 Feb 2020 06:52:27 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::529; helo=mail-ed1-x529.google.com; envelope-from=paul@hammant.org; receiver= Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 2CE047DD70 for ; Fri, 7 Feb 2020 06:52:27 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id m8so1215179edi.13 for ; Thu, 06 Feb 2020 22:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hammant.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UNX081FbzLMSWtgDSPFDKf8BEyYh372RvKhONtIPmPE=; b=lquyhCMp54z6lyG9eKm5jtn/Uej3LECKxl2Ujvf++yVIWJHEW1sCfghP3y/5sAJsI9 QIJLEI0E/FWYPoUH4MGrkTo0iT8kcXRUnjIMQVZDI4VL6bJxXkjfh1qBvUmof8zS/cs+ VnrFknW+7dsXx+yMmJtKP/46nemhxYmKCIS7Pod+eMZ+Nt8YMzcgDFR2Qc7wmXwXRrXf fLjtiMEfXoO9gmdgLoWbA/BRHIKonI7EGZI+Xy1DJtE8glevfteCxggxe3hRmTaUiz+c IFY5c6AN3undXRkIuLkctwhrrZFzEoEhDKoYvWjisOBr5/saxiVCVwP2UO8GvajlUAib jwnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UNX081FbzLMSWtgDSPFDKf8BEyYh372RvKhONtIPmPE=; b=JOE5Bgu6bQvaC02s9d9j4lyXd9+u+9D8BdyoeLOHxNEfGIELa1ngiUC9ANdWBlnWBN 6hhgabQs876/3aZqxPI89PAN9Fhq3WCp5tK+ytRqEjvqHUwF4FSoc62GVN4N8ijZH0TJ C3JkpkKHkHNTsq6BMsiQ4EU+h26Y8YB1L8KAsBEdePtBzhlH+QcYef3PWvlHIWhKA+Uq veKqnkjyMj0XNphoYrEl8YXoROo6gdrw/adDOmBDhPK2JfOE1rrnbgLVb3UYmxkvQlHz 4rm/IwVYWfXDqaKsROFUWVWrnGiayFVmwrJ1bNpRjGLw0na+YrVfkhkq5Xou+isdMUtx EvOA== X-Gm-Message-State: APjAAAWWLhGzHjg2foZoD4Bm4/6ooDwVzxDSLVCVbzta+g5WFeR8R2mC OeMPemwCc9Rq4CQ+Sa22nuXWe84dUYFtDF797pAUQw== X-Google-Smtp-Source: APXvYqyhc5Gyc+GiL8UbED3FbLfrslcPSCMkbfCFYGUyfpoZAjMOnLbquKwzQtalGsc9BoBd4mFc1FDDZhzLf7dbXuQ= X-Received: by 2002:aa7:d64f:: with SMTP id v15mr6409835edr.71.1581058346511; Thu, 06 Feb 2020 22:52:26 -0800 (PST) MIME-Version: 1.0 References: <6E9819BE-B506-467B-8758-54222B28CED5@bandcamp.com> In-Reply-To: <6E9819BE-B506-467B-8758-54222B28CED5@bandcamp.com> From: Paul Hammant Date: Fri, 7 Feb 2020 06:52:15 +0000 Message-ID: Subject: Re: False conflict with interleaved merge commits To: Daniel Dickison Cc: users@subversion.apache.org Content-Type: multipart/alternative; boundary="0000000000001d0c8f059df6d59d" --0000000000001d0c8f059df6d59d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here=E2=80=99s a similar one - https://paulhammant.com/2015/10/05/subversion-merge-limitations-not-in-perf= orce/ On Fri, Feb 7, 2020 at 6:31 AM Daniel Dickison wrote: > We think we=E2=80=99ve found a bug in Subversion=E2=80=99s conflict detec= tion during merge > operations that results in a false conflict. It occurs after two =E2=80= =98merge=E2=80=99 > commands are committed in reverse order between two branches, and then a > subsequent merge is attempted. I=E2=80=99ve attached a repro script that > illustrates this problem using svn 1.13.0, and goes at least as far back = as > svn 1.8.19, on MacOS 10.14.6. > > To summarize: > 1. Create trunk and branch1 > 2. Commit an edit to file mu in trunk > 3. Commit an edit to file iota in branch1 > 4. Merge trunk -> branch1 > 5. Merge branch1 -> trunk > 6. Commit trunk > 7. Commit branch1 > 8. Commit further edits to mu in trunk > 9. Attempt to merge trunk into branch > > At step 9, svn appears to have forgotten about the merge from steps 4 and > 7 and shows a conflict on mu that has only been edited in trunk. > > Strangely, the conflict goes away if you flip the order of steps 2 and 3, > or commit the merge from step 4 first. While that order of committing > merges is typical, this interleaved ordering can arise pretty naturally > between two developers working on the same branch. > > Does this sound like a legit bug? > > Thanks, > Daniel > > > --0000000000001d0c8f059df6d59d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Feb 7, 2020 at 6:31 AM Daniel Dick= ison <daniel@bandcamp.com>= wrote:
We think we=E2=80=99ve foun= d a bug in Subversion=E2=80=99s conflict detection during merge operations = that results in a false conflict. It occurs after two =E2=80=98merge=E2=80= =99 commands are committed in reverse order between two branches, and then = a subsequent merge is attempted. I=E2=80=99ve attached a repro script that = illustrates this problem using svn 1.13.0, and goes at least as far back as= svn 1.8.19, on MacOS 10.14.6.

To summarize:
1. Create trunk and branch1
2. Commit an edit to file mu in trunk
3. Commit an edit to file iota in branch1
4. Merge trunk -> branch1
5. Merge branch1 -> trunk
6. Commit trunk
7. Commit branch1
8. Commit further edits to mu in trunk
9. Attempt to merge trunk into branch

At step 9, svn appears to have forgotten about the merge from steps 4 and 7= and shows a conflict on mu that has only been edited in trunk.

Strangely, the conflict goes away if you flip the order of steps 2 and 3, o= r commit the merge from step 4 first. While that order of committing merges= is typical, this interleaved ordering can arise pretty naturally between t= wo developers working on the same branch.

Does this sound like a legit bug?

Thanks,
Daniel


--0000000000001d0c8f059df6d59d--