"Bert Huijben" <b...@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
