Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B27C91893C for ; Sun, 11 Oct 2015 12:21:28 +0000 (UTC) Received: (qmail 99301 invoked by uid 500); 11 Oct 2015 12:21:23 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 99253 invoked by uid 500); 11 Oct 2015 12:21:23 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 98946 invoked by uid 99); 11 Oct 2015 12:21:23 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Oct 2015 12:21:23 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 1F1631A0921 for ; Sun, 11 Oct 2015 12:21:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=wandisco.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id D5cs2Pj6WlJj for ; Sun, 11 Oct 2015 12:21:12 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 166C2201F9 for ; Sun, 11 Oct 2015 12:21:12 +0000 (UTC) Received: by ignr19 with SMTP id r19so2998376ign.1 for ; Sun, 11 Oct 2015 05:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mQyjRT9yNhlx+zv8o2j0HrtgPW56nRq4438uPEDNoLc=; b=nv8/FSA+fv0nigiFVZIql/MXssNdismI1mz2KNFQ//yTp5ydVEz98LGlY765vAHp9g mXXdrn9hlGXNoRLycgRJCMno7pDrXMuOZlH8cjty+6j5v6vOPsQWZxJ+dw/uQm+R/N5f N2/guuxDdrPgArAMAQ+whC2jx/NswkqnV58rk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mQyjRT9yNhlx+zv8o2j0HrtgPW56nRq4438uPEDNoLc=; b=ZS+gO52KmR6qOJ153FPRAxznSNXz7RnkwoNLlvttk82vGuOHL9xHspvFMqhddgGVVT PiYjIOQxFKmkhMtZYCvxOEf4OB0XiGmy9xckH47lsyblIVMcI24cMRxecxUu1Za7ZrBu U8HUR8axOL2cYtaGis/KgI/SZvoU8HWGJnqY3cTpLo7UGoouEhINDOuy5YSAU6yGZRhv zLNnhIp1kmaPQkeb49XCqKTphj6cUVWTyTps4Kn+2JsgR0Ali/FL3+2XudILu4v1cVF7 gX1xNeU+ZrOyxiVIiFJJ/Qfh1tIZ5KO+0I1bHXYWynb9XB6jt2SJJA83dDAMyW8HjNC4 BzkQ== X-Gm-Message-State: ALoCoQn2kBRtoSD2Nwnr6zyMCj0/cW0LYKJi6vzWsoqlrhqEvYiKYJn2vtRGSAMQMcNkJi3x/xpi MIME-Version: 1.0 X-Received: by 10.50.3.37 with SMTP id 5mr7370590igz.96.1444566065365; Sun, 11 Oct 2015 05:21:05 -0700 (PDT) Received: by 10.50.225.71 with HTTP; Sun, 11 Oct 2015 05:21:05 -0700 (PDT) In-Reply-To: References: <20150921210118.GF1955@tarsus.local2> <5602746B.9050800@apache.org> <56027A52.1090806@apache.org> Date: Sun, 11 Oct 2015 14:21:05 +0200 Message-ID: Subject: Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9 From: Stefan Fuhrmann To: Evgeny Kotkov Cc: Julian Foad , =?UTF-8?Q?Branko_=C4=8Cibej?= , Johan Corveleyn , dev Content-Type: multipart/alternative; boundary=089e013c6e9a2e6a4d0521d33f48 --089e013c6e9a2e6a4d0521d33f48 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 1:07 PM, Evgeny Kotkov wrote: > Stefan Fuhrmann writes: > > > This is not about performance, it is about API guarantees and functional > > stability. So, yes that is an optimization in the sense of "making it > better > > than before". And no, we should not go back to worse unless there is no > other > > practical way. > > Exactly how does this change make the situation better in practice? In > other > words, what particular use cases is it supposed to fix? > Any use-case that depends on this information, IOW all those that you are afraid may have been broken by the new API. Decoupling API behaviour from implementation details is about preventing future breakage in the callers of that API. Two proposed backend changes come to my mind that may affect the conditions under which new noderevs will be created: * non-bubble-up directory representations, e.g. Brane's approach * "native" support for move / rename possibly not creating a new ID I'm not saying that any of these will be implemented in the near future but those ideas and proposals demonstrate that we cannot assume specifics of the DAG implementation. > I see it as an abstract change that alters the behavior of many different > calling sites. Given that the practical benefits are unknown, I think that > we should restore the known stable behavior, and avoid problems coming > from various places. > As shown above, the behaviour is not know stable. In fact, SVN 1.5 had to jump through loops to mimic the original behaviour by adding "uniquifiers" to shared representations. If it was a mere theoretical issue, I wouldn't have bothered addressing it. -- Stefan^2. --089e013c6e9a2e6a4d0521d33f48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 8, 2015 at 1:07 PM, Evgeny Kotkov <evgeny.kotkov@visuals= vn.com> wrote:
Stefan Fuhrmann <s= tefan.fuhrmann@wandisco.com> writes:

> This is not about performance, it is about API guarantees and function= al
> stability. So, yes that is an optimization in the sense of "makin= g it better
> than before". And no, we should not go back to worse unless there= is no other
> practical way.

Exactly how does this change make the situation better in practice?= =C2=A0 In other
words, what particular use cases is it supposed to fix?

Any use-case that depends on this information, IOW all
=
those that you are afraid may have been broken by the
<= div>new API.

Decoupling API behaviour from implementation= details is
about preventing future breakage in the callers o= f that API.
Two proposed backend changes come to my mind that
may aff= ect the conditions under which new noderevs will
be created:

* non-bubble-up directory representations, e.g. Brane's approach=
* "native" support for move / rename possibly not = creating a new ID

I'm not saying that any = of these will be implemented in
the near future but those ide= as and proposals demonstrate
that we cannot assume specifics of the DAG = implementation.
=C2=A0
I see it as an abstract change that alters the behavior of many different calling sites.=C2=A0 Given that the practical benefits are unknown, I think= that
we should restore the known stable behavior, and avoid problems coming
from various places.

As shown above, th= e behaviour is not know stable. In fact,
SVN 1.5 had to jump = through loops to mimic the original
behaviour by adding "= ;uniquifiers" to shared representations.
If it was a me= re theoretical issue, I wouldn't have bothered
addressing it.

-- Stefa= n^2.
--089e013c6e9a2e6a4d0521d33f48--