> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 27 november 2015 10:28
> To: Daniel Shahaf <d.s_at_daniel.shahaf.name>
> Cc: Bert Huijben <bert_at_qqmail.nl>; 'Branko Čibej' <brane_at_apache.org>;
> dev_at_subversion.apache.org
> Subject: Re: svn commit: r1716548 -
> /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
>
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>
> > Philip Martin wrote on Thu, Nov 26, 2015 at 13:46:39 +0000:
> >> I suppose one way to fix this would be to ensure that every BDB revision
> >> generates a new node-revision-id.
> >
> > I wouldn't call this a fix; I think it is a workaround. A "fix" would
> > be to figure out why bdb reports the wrong revision number, not to make
> > the place it wrongly looks the value up in contain the right value.
>
> I don't understand whay you want. BDB does not store the base revision
> in the txn, it stores the base node-revision-id instead. Revisions
> usually map 1:1 to the base node-revision-ids but the editor drive
> "begin_txn, commit" breaks this because it creates a revision that
> shares the base node-revision-id with the previous revision. My patch
> makes the mapping 1:1 so storing the node-revision-id works.
>
> If you expect a patch that causes BDB to change the txn storage on disk
> to include the base revision (or instead of the base node-revision-id?)
> then you will have to explain why that is better.
Another option would be to just store the revision number in the string representation of the txn-id and keep the on-disk behavior the same as it is today. Can we just add an (optional) component there?
Any fix that would make us load the txn back the way it was before serializing it would be a good fix for me.
I would also be +0 on a fix that makes the base rev lower directly on creating the txn. (I'll fix mod_dav in that case)
But I think we should at least behave the same before and after serializing the txn.
Bert
Received on 2015-11-27 10:32:14 CET