Daniel Shahaf wrote: > Julian Foad wrote on Tue, 21 Aug 2018 14:12 +0100: > > * We could ignore the rep cache during commit-txn (in existing API: > > set fs_fs_data.rep_sharing_allowed = FALSE), then make a separate call > > to update the rep cache afterwards. > > "A separate call to update the rep cache afterwards" --- something like > `svnadmin backfill-rep-cache -r 40:50` --- could be generally useful, to > admins who had disabled rep-cache or deleted rep-cache.db (intentionally > or otherwise) and want to rebuild the rep-cache without a dump/load cycle.
Yes, I totally agree, that would be very useful functionality in its own right. > (To be clear, I'm not opining that the logic should be in svnadmin; that > was just a pseudocode example.) Agreed. Also we might like to teach "svnadmin verify" to check whether the cache is complete. > > * We could change FSFS to allow selectively disabling part 2 (look up > > props) during the 'commit' step while keeping part 3 (update) enabled > > (split that flag into two), and disable part 2 only. > > > > With these first two options, the rep cache would deduplicate only file > > contents, and that is fine. Deduplication of properties is relatively > > minor. > > > > * We could change FSFS such that commit-txn no longer depends on the > > rep-cache content, by moving the props deduplication to the txn-building > > phase. > > > > * We could ensure the rep cache is synchronized across repositories > > before each commit-txn. > > Who's "We" in the last sentence? WANdisco, possibly requiring additional support from Subversion. (I haven't thought about how it might work.) > > Could I please hear your thoughts? How appropriate might it be to make > > such changes in FSFS, if they are potentially beneficial for other users > > of the FSFS API, or other considerations? > > Thanks for sharing the wider context. -- - Julian
