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.

-- 
Philip Martin
WANdisco