Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 17095200C05 for ; Mon, 23 Jan 2017 12:10:34 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 15D8D160B58; Mon, 23 Jan 2017 11:10:34 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 66C74160B3E for ; Mon, 23 Jan 2017 12:10:33 +0100 (CET) Received: (qmail 65093 invoked by uid 500); 23 Jan 2017 11:10:27 -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 65082 invoked by uid 99); 23 Jan 2017 11:10:27 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jan 2017 11:10:27 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id ADC4DC03D0 for ; Mon, 23 Jan 2017 11:10:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.999, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id T0CamkSuz3Wf for ; Mon, 23 Jan 2017 11:10:24 +0000 (UTC) Received: from smtp1.oma.be (smtp1.oma.be [193.190.144.13]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id C1E965F22F for ; Mon, 23 Jan 2017 11:10:23 +0000 (UTC) Received: from [192.168.141.22] (pvh-pc.oma.be [192.168.141.22]) by smtp1.oma.be (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id v0NBAGIN018052; Mon, 23 Jan 2017 11:10:16 GMT Subject: Re: merginfo corruption? To: Johan Corveleyn , users@subversion.apache.org References: <1275f98d-03ff-20b9-d34d-ee8dbd7a0fa4@oma.be> <2f87306c-c020-e7c3-c27a-b4b31664a8df@oma.be> <20161103123218.GH9611@ted.stsp.name> From: Peter van Hoof Organization: Royal Observatory of Belgium Message-ID: <134f1898-2e61-b1d7-a18c-d8d4bd5bb8d7@oma.be> Date: Mon, 23 Jan 2017 12:10:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20161103123218.GH9611@ted.stsp.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit archived-at: Mon, 23 Jan 2017 11:10:34 -0000 Hi, I have been sidetracked by other work for a while, but would like to get back to this now... >> I double-checked this and checked out the branch at r8689. This is the result >> >> % svn co svn://svn.nublado.org/cloudy/branches/backtrace@8689 >> % cd backtrace/ >> % svn proplist --verbose source/ >> [...snip...] >> /trunk/source:8667-8688 >> >> So the revision in question is definitely marked as merged there... This >> looks OK, which is also consistent with the fact that subsequent merges from >> trunk showed no problems (r8784, r8788, r8815, r11144). > > You're only looking at one path. Mergeinfo is only inherited to paths > which do not have an svn:mergeinfo property themselves. > > In my example above, svn:mergeinfo on the root of the working copy > is irrelevant for any child (directory or file) within subtree A. > Only mergeinfo on subtree A is considered for those children (unless > of course where children have svn:mergeinfo themselves). The backtrace branch has only been maintained by me, and my routine has always been to merge all changes from the root of the trunk to the root of the branch and then commit from the root of the branch. So I would expect the mergeinfo to be the same on subdirectories or individual files. However, when I checked this, I found this not to be the case. These paths have separate mergeinfo records at r8689: data/lamda/masterlist/Lamda.ini source tsuite/auto/chianti_all_cool.dat tsuite/auto/chianti_all_cool.in Apart from "source" they are all files. The full mergeinfo record for source is svn:mergeinfo /branches/HfsLines/source:6561-8024 /branches/SED/source:6190-7044 /branches/WangYe/source:5202-5690 /branches/block/source:6454-6465 /branches/cden/source:6478-6586 /branches/chianti/source:5345-5686,6680-6806 /branches/collapsed/source:7331-8615 /branches/convergence/source:8443-8533,8561-8633 /branches/convfix/source:7216-7234 /branches/depart/source:7256-7655 /branches/diatoms/source:4635-5051 /branches/fixct/source:5862-5945 /branches/gtest/source:7057-7198 /branches/h2star/source:5156 /branches/ionrec/source:4983-5281 /branches/linesInit/source:6627-6633 /branches/newmole/source:502-6043 /branches/nstout/source:8422-8435 /branches/optnl/source:6638-6757 /branches/ots2/source:6379,6393-6394,6429-6430,6448 /branches/parser/source:3753,3755,3763 /branches/parser2/source:7036-7070 /branches/romas3/source:6262-6786 /branches/stout/source:6885-6945,6976-7373,7388-7415,7417-7420,7668-7671,8202-8203,8378-8395 /branches/stout1/source:8135-8171 /branches/stout2/source:6109-6538,7581-7619,7694-7706 /branches/stout3/source:7626-7633,7635-7663 /branches/sup/source:7503-7533 /trunk/source:8667-8688 So it has the same information for /trunk as the record at the root. The three files with individual mergeinfo records look different. One example for tsuite/auto/chianti_all_cool.dat is svn:mergeinfo /branches/FixWvlng/tsuite/auto/chianti_all_cool.dat:7890-7912 /branches/collapsed/tsuite/auto/chianti_all_cool.dat:8609-8615 /branches/convergence/tsuite/auto/chianti_all_cool.dat:8443-8533,8561-8633 /branches/nstout/tsuite/auto/chianti_all_cool.dat:8422-8435 /branches/stout/tsuite/auto/chianti_all_cool.dat:8202-8203,8378-8395 So at revision 8689, the mergeinfo records at the root and the source subdirectory both indicate that r8669 is already merged at that point. Yet, when I do the merge now (at the head of this branch), it wants to merge changes in source/rt_continuum_shield_fcn.cpp from r8669. For me this points to corruption in the mergeinfo record or a bug in subversion (or both of course...). So I would like to consider the svn-mergeinfo-normalizer tool that was mentioned earlier in this thread. But I need additional guidance on how to compile it and how I should use it. Do I need to fix the trunk, or the development branch, or both? How does this compare to the mergeinfo-sanitizer.py script? Cheers, Peter.