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

Re: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

From: Branko ─îibej <brane_at_apache.org>
Date: Wed, 25 Nov 2015 23:42:34 +0100

On 25.11.2015 23:27, Bert Huijben wrote:
>> -----Original Message-----
>> From: rhuijben_at_apache.org [mailto:rhuijben_at_apache.org]
>> Sent: woensdag 25 november 2015 22:31
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1716548 -
>> /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
>> Author: rhuijben
>> Date: Wed Nov 25 21:31:20 2015
>> New Revision: 1716548
>> URL: http://svn.apache.org/viewvc?rev=1716548&view=rev
>> Log:
>> Create simpler reproduction recipe for BDB issue julian found using
>> svnmover+BDB+ra_serf.
> Any BDB hackers around that know the background behind this?
> The question is: Why isn't the base revision properly saved in the txn when the HEAD revision is a no-op commit?
> I'm guessing that we safe something else and then accidentally fetch the last modified revision of that and use it as the BASE revision of the transaction.

Used to be that BDB would take the BASE from the reporter as the BASE
for the commit txn, and only change it in the rebase phase of the
commit; whereas fsfs uses the current HEAD. Don't know if anyone ever
changed that in BDB.

In general it shouldn't matter which BASE the commit txn begins with;
but if it's HEAD, we can bail out earlier in the presence of certain
kinds of conflicts.

-- Brane
Received on 2015-11-25 23:42:38 CET

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