> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_apache.org]
> Sent: woensdag 25 november 2015 23:43
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1716548 -
> /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
>
> 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.
Minor update on my research:
It looks like BDB stores a 'base node-revision-id' in the transaction instead of the actual base revision passed.
New for 1.10 we started verifying incoming revisions in mod_dav_svn to produce better out of date messages in a few extreme corner cases.
In this case it checks that the passed BASE revision is not newer than the revision against which the transaction was opened.
But now we found that BDB has a case where the base revision after reloading the txn from disk may be lower than the one that was in there when the txn was started (before reloading).
I can see reasons why BDB wants to use that lower base revision... but having a txn produce a different result from svn_fs_txn_base_revision() before and after reloading by name is not good.
Bert
Received on 2015-11-26 00:18:24 CET