From users-return-27071-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Wed Apr 25 14:03:31 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9E08B180676 for ; Wed, 25 Apr 2018 14:03:30 +0200 (CEST) Received: (qmail 67300 invoked by uid 500); 25 Apr 2018 12:03:29 -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 67287 invoked by uid 99); 25 Apr 2018 12:03:28 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2018 12:03:28 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 4BF28C02CF for ; Wed, 25 Apr 2018 12:03:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.31 X-Spam-Level: * X-Spam-Status: No, score=1.31 tagged_above=-999 required=6.31 tests=[DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=yahoo.se Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 1OwoRz4R8bkr for ; Wed, 25 Apr 2018 12:03:26 +0000 (UTC) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 9BE535F174 for ; Wed, 25 Apr 2018 12:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.se; s=s2048; t=1524657798; bh=d4A+3mqBS2Ketciy/kHmxWHIEkaqLy3II7inlr0HhBY=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=rkseso82qLD91d3wOFwrUl0R7lGh7W5S+HV3bmfh+9uLc0Wa+0diyJbR213MnNFU9eMlrJhyKAA7SRJY4W9LmIB2P5nxCW/fTfmAm6LVCgCjS+d9bE9LvTWzpKxlPamWjjZfIla9NUk0yNRIqhd+QJqxyghopQ0nZTotfxV2wCRKJDhkRloBnr1FTO8ajnTReYYKE4hfTcpVkQLYBgvfqkmowq5Dnhwn5B6jfRMwX3XTgu/OZg7ac2proFUIl/GadrLBAd8zNo2es+Rbx1aOWmRRzAxiYV43hlI4Qvx3BPKhKFbgUGQtMwrz9bit/+KijU1Q5L5LKDHac0G6OupaEQ== X-YMail-OSG: c0LCbbwVM1nfBwPNFgFcStuz3Wxso8cQZ1QsiBIIdHeBNudLczcyqv5mpJLM9HH NMCdn1xBJiB_wMrT3Ms6TI72h22I7ZWOX.lPsvUVY5iY6HJ70u5qSu41EgHgNJF8KIBMVL8OLQ5Y udiV9L0iuIYvXtGGLvmzjq.o7J0T5KNhYrtMJm_B1IgBQWjeeQfb2Gmwnvd4R7aYEzry0Du3jHua 24LfL9WZvwxs1b4qWgKo9yrRFPbJ4X3kDH5iBFURJgPLfTSXau1faAMWFOu9jUad6.75EZRVL0FD DqF.1sCRHh17jgpDke9GDdiChEH9jzHAnSlgfiD11lh_iHerMw3AsOTVB32wvEoPdIkZMWsnJNRx .90i8DiEzUX61VwAgszioKdxurSB5LLNA_AEJshqmRsTbwVk3b0.FYSz_KGHnno8fTbC24XFOO3W ARqhUPVKlG4RcDKtB37G8KfaUKSO_1ZjYhjl57uCfMnUVW9BVKMBDYNRqRrdvgvEB5i0XJwT9Ngo 5w1RebuFF6V5edB0DtXxJD3.87yYTN6H_r1.0UGiNZNi56vJNnfRQ4tIf8ENQ_47X_EP5zNNHj9u idHgpiDM8T2doZW9JVPth0yc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 25 Apr 2018 12:03:18 +0000 Date: Wed, 25 Apr 2018 12:03:17 +0000 (UTC) From: Chris Reply-To: Chris To: Chris , Stefan Sperling Cc: Message-ID: <1641610543.661709.1524657797895@mail.yahoo.com> Subject: Re: Surprising behavior with 1.10 tree conflict resolver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1641610543.661709.1524657797895.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11819 YahooMailBasic Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.189 Safari/537.36 Vivaldi/1.95.1077.60 Hi Stefan and thanks for the reply. (sorry about the top-posting, yahoo's webmail isn't made for proper mail usage) Good idea to try the non-interactive and then resolve after, that seems to get me out of the bind I got into, but I'll probably tell our users to stick to 1.9 for the time being. I'm not sure I'll be able to recreate a test for the strange behavior since it may have to do with this being a very large and very old repo that I'm working on. But I'll give it a try as soon as I have some time to spare and post the result here (or the failure to repeat it in a simple script). /Chris -------------------------------------------- On Wed, 4/25/18, Stefan Sperling wrote: Subject: Re: Surprising behavior with 1.10 tree conflict resolver To: "Chris" Cc: users@subversion.apache.org Date: Wednesday, April 25, 2018, 1:37 PM On Wed, Apr 25, 2018 at 11:04:13AM +0000, Chris wrote: > I'm trying out subversion 1.10 and it's going both good and bad. > > The good thing is that new interactive conflict resolver works absolutely brilliantly for text conflicts. Great job everyone! > The bad news is that I can't resolve my tree conflicts. > > Let me prefix this with saying that the corporate svn server I'm using is badly setup and slow as molasses (*), which may play a part here, but even without that, I don't understand the behavior I am seeing. It is probably correct as-is, but unfortunately seems to make svn 1.10 impossible to use for me. > > I'm trying a merge from trunk to my branch on a project with this kind of chronology for a conflict: > * branch created at r105778 (the file "foo" exists on trunk) > * "foo" modified on trunk in r106352 > * "foo" moved and renamed on branch in r106610 > * merge trunk to branch in rev 107369 (first merge to the branch) > > But when it hits "foo" in the resolver, it prints: > > Searching tree conflict details for foo in repository: > Checking r... > > Where started at recent changes in "foo" but is going backwards to > revisions long before the branch root, i.e. revisions before 105778. I don't > understand how any of these should affect the merge resolution since they are > older than when I created the branch so I'm guaranteed to already have those > revisions (?). I even *think* it is continuing further back than when the foo > was added to trunk. And this is taking a really really long time with our > server. We're talking minutes per revision, even causing timeout from the > server so I can't resolve the conflict. Shouldn't it have stopped going > backwards beyond the revisions that I branched off on? (the "--stop-on-copy" > revision) Your expectations are not unreasonable but keep in mind that the resolver works in the context of one particular file or directory. When it traces history back and traverses copies it cannot tell whether those copies were creating a new branch or copy an item within a branch; in the data model, these twoI cases look 100% alike. We will need a more concrete example to confirm the problem and if possible fix the behaviour. Could you try to write a script which starts by creating a fresh and empty repository, adds files and directories as necessary, and creates this specific tree conflict situation where it traces history further back than necessary? That would help us a lot. As a workaround, if this is a blocking issue for you, you could run problematic merges with --non-interactive. This will postpone all conflicts and suppress the interactive resolver. This allows you to resolve the problematic conflict manually as you would have done in SVN 1.9. Once the problematic conflict has been resolved, you can resolve all remaining conflicts interactively by running 'svn resolve'. Problems like this are not expected but unfortunately not inevitable either. The resolver is new in this release and has not seen much real world testing, even though we gave the community some early opportunities in form of alpha releases and release candidates. Feedback such as yours is very much appreciated because we cannot improve the resolver without it. Thanks, Stefan -----Inline Attachment Follows-----