Julian Foad <julianfoad_at_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
Received on 2015-03-03 13:46:30 CET