Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of stefan.fuhrmann@wandisco.com
 designates 209.85.213.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+t0gk3tfr-qycN6ppPP3UY5aykaERU-64nfTi9nKS0b7pZR2A@mail.gmail.com>
References: 
 <CA+t0gk3tfr-qycN6ppPP3UY5aykaERU-64nfTi9nKS0b7pZR2A@mail.gmail.com>
Date: Thu, 11 Dec 2014 11:51:19 +0100
Message-ID: 
 <CA+t0gk0WOPT=JdFtnBh8ehAkFecwbOxmQmhtoCUDQRYN2ZTguQ@mail.gmail.com>
Subject: Re: 'svn up' may cause inconsistent mergeinfo
From: Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>
To: Subversion Development <dev@subversion.apache.org>
Content-Type: multipart/mixed; boundary=90e6ba5bc5c56fd8a20509ee8eca

--90e6ba5bc5c56fd8a20509ee8eca
Content-Type: multipart/alternative; boundary=90e6ba5bc5c56fd89c0509ee8ec8

--90e6ba5bc5c56fd89c0509ee8ec8
Content-Type: text/plain; charset=UTF-8

On Thu, Dec 11, 2014 at 10:39 AM, Stefan Fuhrmann <
stefan.fuhrmann@wandisco.com> wrote:

> Hi,
>
> There is yet another problem with sub-tree mergeinfo:
>
> (1) User A performs a sub-tree merge causing the mi property
>   to be added to the sub-node. No commit, yet.
> (2) User B commits a merge at the branch root, modifying its m/i.
> (3) User A updates and commits their merge.
>
> Now, the sub-tree mergeinfo does not reflect the changes
> made to the root node m/i. If the latter are operative on that
> sub-tree, the data is inconsistent and can create conflicts.
>
> The attached script demonstrates the problem.
>
> -- Stefan^2.
>

... and there is the script.

--90e6ba5bc5c56fd89c0509ee8ec8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 11, 2014 at 10:39 AM, Stefan Fuhrmann <span dir=3D"ltr">&lt;<a href=
=3D"mailto:stefan.fuhrmann@wandisco.com" target=3D"_blank">stefan.fuhrmann@=
wandisco.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>There i=
s yet another problem with sub-tree mergeinfo:<br><br></div>(1) User A perf=
orms a sub-tree merge causing the mi property<br></div>=C2=A0 to be added t=
o the sub-node. No commit, yet.<br>(2) User B commits a merge at the branch=
 root, modifying its m/i.<br></div>(3) User A updates and commits their mer=
ge.<br><br></div>Now, the sub-tree mergeinfo does not reflect the changes<b=
r>made to the root node m/i. If the latter are operative on that<br></div>s=
ub-tree, the data is inconsistent and can create conflicts.<br><br></div>Th=
e attached script demonstrates the problem.<br><br></div>-- Stefan^2.<br></=
div>
</blockquote></div><br></div><div class=3D"gmail_extra">... and there is th=
e script.<br></div></div>

--90e6ba5bc5c56fd89c0509ee8ec8--

--90e6ba5bc5c56fd8a20509ee8eca
Content-Type: application/x-sh; name="mergeinfo-inconsistency.sh"
Content-Disposition: attachment; filename="mergeinfo-inconsistency.sh"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_i3k0ahra0

IyEvYmluL2Jhc2gKClNWTj1+L2RldmVsb3AvdHJ1bmsvc3VidmVyc2lvbi9zdm4vc3ZuClNWTkFE
TUlOPX4vZGV2ZWxvcC90cnVuay9zdWJ2ZXJzaW9uL3N2bmFkbWluL3N2bmFkbWluCkJBU0VfUEFU
SD1gcHdkYAoKI2NsZWFuIHVwIGFueSBvbGQgbWVzcwpybSAtcmYgJEJBU0VfUEFUSC93YwpybSAt
cmYgJEJBU0VfUEFUSC9yZXBvCmNkICRCQVNFX1BBVEgKCiNuZXcgcmVwbwokU1ZOQURNSU4gY3Jl
YXRlIHJlcG8KJFNWTiBjbyBmaWxlOi8vJEJBU0VfUEFUSC9yZXBvIHdjCmNkIHdjCgojYmFzaWMg
cHJvamVjdCBzdHJ1Y3R1cmUKbWtkaXIgdHJ1bmsKZWNobyAiaW5pdGFsIGNvbnRlbnQiID4gdHJ1
bmsvZm9vCiRTVk4gYWRkIHRydW5rCiRTVk4gY2kgLW0gIm1haW4gbGluZSIKCiNicmFuY2ggaXQK
JFNWTiBjcCB0cnVuayBicmFuY2gKJFNWTiBjaSAtbSAiYnJhbmNoIHBvaW50IgoKI3RocmVlIHRy
aXZpYWwgbW9kaWZpY2F0aW9ucwplY2hvICJ2ZXJzaW9uIDEKMQoyCjMiID4gdHJ1bmsvZm9vCiRT
Vk4gY2kgLW0gIm1vZCAxIgplY2hvICJ2ZXJzaW9uIDIKMQoyCjMiID4gdHJ1bmsvZm9vCiRTVk4g
Y2kgLW0gIm1vZCAyIgplY2hvICJhZGQgbGluZSA0IiA+PiB0cnVuay9mb28KJFNWTiBjaSAtbSAi
bW9kIDMiCmVjaG8gImFkZCBsaW5lIDUiID4+IHRydW5rL2ZvbwokU1ZOIGNpIC1tICJtb2QgNCIK
CiNtZXJnZXMgYXQgcHJvamVjdCByb290CiRTVk4gdXAgLgokU1ZOIG1lcmdlIC1jIDMgXi90cnVu
ayBicmFuY2gKJFNWTiBjaSAtbSAibWVyZ2UgbW9kIDEiCiRTVk4gdXAgLgokU1ZOIG1lcmdlIC1j
IDUgXi90cnVuayBicmFuY2gKJFNWTiBjaSAtbSAibWVyZ2UgbW9kIDMiCgojcHJvYmxlbWF0aWMg
c3VidHJlZSBtZXJnZSAodXN1YWxseSBkaWZmZXJlbnQgdXNlci93YykKJFNWTiB1cCAtcjcgLgok
U1ZOIG1lcmdlIC1jIDQgXi90cnVuay9mb28gYnJhbmNoL2ZvbwokU1ZOIHVwIC4KJFNWTiBjaSAt
bSAibWVyZ2UgbW9kIDIiCgojc2hvdyBpbmNvbnNpc3RlbmN5OyBtL2kgZm9yIC9icmFuY2gvZm9v
IGlzIHdyb25nCmVjaG8gImVsaWdpYmxlIGZvciBtZXJnaW5nIGZyb20gL3RydW5rIHRvIC9icmFu
Y2giCiRTVk4gbWVyZ2VpbmZvIC0tc2hvdy1yZXZzIGVsaWdpYmxlIF4vdHJ1bmsgYnJhbmNoCmVj
aG8gImVsaWdpYmxlIGZvciBtZXJnaW5nIGZyb20gL3RydW5rL2ZvbyB0byAvYnJhbmNoL2ZvbyIK
JFNWTiBtZXJnZWluZm8gLS1zaG93LXJldnMgZWxpZ2libGUgXi90cnVuay9mb28gYnJhbmNoL2Zv
bwoKI2RlbW9uc3RyYXRlIHRoYXQgaXQgYWN0dWFsbHkgaHVydHMKI1RoaXMgZXJyb25lb3VzbHkg
dHJpZXMgdG8gbWVyZ2UgcjUgYSBzZWNvbmQgdGltZSBhbmQgY3JlYXRlcyBhIGNvbmZsaWN0Lgok
U1ZOIHVwIC4KIyB3b3VsZCB3b3JrOiAkU1ZOIG1lcmdlIF4vdHJ1bmsgYnJhbmNoCiRTVk4gbWVy
Z2UgXi90cnVuay9mb28gYnJhbmNoL2ZvbwoK
--90e6ba5bc5c56fd8a20509ee8eca--