[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Tonight's svn-role merges - bug analysis

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 17 Apr 2014 11:12:15 +0000

There were 9 merges tonight (r1588145:r1588153). The log messages were
all correct, but the Nth merge removed from STATUS the (2N)th merge's
entry. As a result, the first merge (N=0) was correct, but the others
either removed the wrong STATUS entry or removed no entry.

I think this is due to a bug in the relatively new $parno handling. I
believe the parno code wasn't on the VM until yesterday, even though
it's been in HEAD for a while.

The code stows $parno in the %entry structure at parse time, and then
loops over the entries in Approved and merges them. The first merge
deletes the ($entries[0]->{parno})th paragraph from STATUS. The second
merge then deletes the ($entries[1]->{parno})th paragraph from the
file... which is wrong; it should be deleting the ($entries[1]->{parno}-1)th
paragraph instead, since the first merge has happened, and
$entries[0]->{parno} < $entries[1]->{parno}.

The fix would be to change the $parno accounting as follows: before
$entry{parno} is used, subtract from it the number of entries already
merged in this run. (Entries are currently merged in file order, so
none of the already-merged-in-this-run entries would have a ->{parno}
greater than $entry{parno} of the entry about to be merged.)


P.S. It would be a good idea to have some sort of test suite for

There is no @entries array; that was just pseudosyntax for "the first entry".
Received on 2014-04-17 13:12:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.