> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: vrijdag 27 november 2015 13:46
> To: Bert Huijben <bert_at_qqmail.nl>
> Cc: 'Daniel Shahaf' <d.s_at_daniel.shahaf.name>; '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
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> > 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?
>
> I suppose that would work. It might break any third-party code that
> parses BDB txn-ids. There probably isn't any such code for BDB but I am
> aware of a comparable issue in some 3rd party FSFS code
>
> > 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)
>
> I think that is the wrong solution. Our public API passes a base
> revision to svn_fs_begin_txn() and I think it would be odd if
> svn_fs_txn_base_revision() did not return the same revision. I think
> that is preserving the behaviour that is most likely to break 3rd party
> code.
>
> I prefer the solution that makes the root path mutable before commit so
> that the revision has a distinct root node-revision-id.
I don't know which solution is better. I just posted the other option.
I always assumed that the textual representation of txn-id was black box though...
I wouldn't have called that part of our API promise. (We should just be able to use ids created by older versions)
@julian, didn't you update the documentation on the related function recently?
Bert
Received on 2015-11-27 14:56:34 CET