Julian Foad <julianf...@btopenworld.com> writes: >> Using svn:date to store txn creation date doesnt't work so well now that >> we allow clients to set svn:date. It might have been better if the txn >> creation date was stored in a separate txn property that was deleted on >> commit. If we were to do that then we would need to expose the internal >> txn value, which would mean svn_fs_txn_prop/proplist could not hide all >> internal txn props. > > Or svn_fs_txn_prop/proplist *could* hide all internal txn props, and we > could add another API for svnadmin to view the txn-creation date.
Okay, here is what I am about to do: 1) Exploit the BDB problem with SVN_FS_TXN_CLIENT_DATE not working as expected in a separate test. Probably, I am also going to create an issue, because without a fix we'd be shipping Subversion 1.9 with a new transaction flag that doesn't work properly on every FS backend. 2) Change svn_fs_txn_proplist() and svn_fs_txn_prop() to hide the internal transaction properties like svn:check-locks and squash this change into the V1 patch. This change would not affect the visibility of svn:date property for transactions, because the property is not internal; we are only going to stop exposing svn:check-ood, svn:check-locks and svn:client-date in our FS API calls. Regards, Evgeny Kotkov
