> -----Original Message-----
> From: Daniel Shahaf [mailto:danielsh_at_apache.org]
> Sent: zaterdag 28 november 2015 18:32
> To: Philip Martin <philip.martin_at_wandisco.com>
> Cc: Bert Huijben <bert_at_qqmail.nl>; 'Branko Čibej' <brane_at_apache.org>;
> Subject: Re: svn commit: r1716548 -
> On Thu, Nov 26, 2015 at 06:17:07PM +0000, Philip Martin wrote:
> > Philip Martin <philip.martin_at_wandisco.com> writes:
> > > I suppose one way to fix this would be to ensure that every BDB
> > > generates a new node-revision-id.
> > To do this we make '/' mutable either when creating the txn, or when
> > commiting the txn. Patches to do both below. Not sure which one is
> > best.
> Making '/' mutable at transaction creation would violate an explicit API
If you interpret it this way FSFS always broke the promise
> /** Set @a *revision to the revision in which @a path under @a root
> * created. Use @a pool for any temporary allocations. @a *revision
> * be set to #SVN_INVALID_REVNUM for uncommitted nodes (i.e.
> modified nodes
> * under a transaction root). Note that the root of an unmodified
> * is not itself considered to be modified; in that case, return the
> * upon which the transaction was based.
> svn_error_t *
> svn_fs_node_created_rev(svn_revnum_t *revision,
And strictly the root directory is not *under* the root.
I'm not sure what the right way to fix this problem is... but calling fsfs
completely broken is not the solution for fixing this inconsistency.
And if you open a transaction against r3... then what is the revision the
transaction is based on?
FSFS and FSX always think so
If both r2 and r3 didn't contain modifications, BDB thinks so (see the
recently added RA C test)
(The commit can even be applied on top of r4, if this doesn't conflict)
Received on 2015-11-28 21:58:31 CET