Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 14 Aug 2012 21:24:19 +0100
From: Daniel Shahaf <danielsh@elego.de>
To: Chris J Smith <chris.smith@intelliflo.com>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Subject: Re: Interesting mergeinfo corruption bug
Message-ID: <20120814202340.GB11545@tarsus.local2>
References: 
 <1B81DC42240AEE4B96F487A2683E7EEB05F196E0A1@THHS2E12BE2X.hostedservice2.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <1B81DC42240AEE4B96F487A2683E7EEB05F196E0A1@THHS2E12BE2X.hostedservice2.net>
User-Agent: Mutt/1.5.21 (2010-09-15)

Chris J Smith wrote on Tue, Aug 14, 2012 at 16:04:22 +0100:
> Hi,
> 
> I've encountered a rather interesting merging bug. We are using the following stack:
> 
> Client side: TSVN 1.7.7 on Windows 7 x64
> Server side: Apache 2.0.27, Subversion 1.7.5 on Windows 2008 Server R2 behind an IIS 7.5 ARR proxy.
> 
> The issue is as follows (with false names of course :-):
> 
> 1. We have trunk and two branches running (ba, bb). Merges have been done from each branch.
> 
> 2. bob merges a revision 12 from ba into trunk. This causes the mergeinfo property to be set on trunk to:
> 
> /svn/project/ba:10,11,12 #(adding the 12).

Not 10-12 ? 

> /svn/project/bb:8,9,13
> 
> 3. bill comes along and immediately merges revision 14 from bb into trunk. This causes the merge info to set on the root to:
> 
> /svn/project/ba:10,11 #(removing the 12?!?!?)
> /svn/project/bb:8,9,13,14 #(adding the 14)
> 
> This unexpectedly removes rev 12 from the mergeinfo for a branch which is not being merged against. Inevitably this means that rev 12 now shows up as eligible again.
> 

Can you provide 'svn log -q -v -r 0:12' output of a repository that
shows the problem?  I can't look into it myself but I think it would be
helpful.

> We've been playing whack a mole with this for a couple of weeks now. The problem is entirely intermittent and there appears to be no way of reliably isolating it (I've tried for days now).
> 
> There is the possibility of human error here either on my understanding or at this end but it's shown up on several people's workstations now.
> 
> Does anyone know why this occurs or can anyone help us?
> 
> Best Regards,
> 
> Chris Smith
> 
> 
> [cid:imageb49554.png@03f105ab.20a84782]
> Best Tech/ Software Provider- PA Awards 3 years running, voted for by Financial Advisers.
> [cid:imageb8bb42.png@42860fd3.72ca41b9]
> 
> The information contained in this message is confidential and may also be privileged. It is intended only for the addressee named above. The unauthorised use, disclosure, copying or alteration of this message is strictly prohibited. If you are not the addressee (or responsible for delivery of the message to the addressee), please notify the originator immediately by return message and destroy the original message. This message and any attachments have been scanned for viruses prior to leaving the originators network. The originator does not guarantee the security of this message and will not be responsible for any damages arising from any alteration of this message by a third party or as a result of any virus being passed on. Registered in England No. 05206315. Registered Office IntelliFlo Limited, Quarrydown, 21E Rydens Road, Walton on Thames, KT12 3AB.
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________