On Fri, Aug 27, 2021 at 9:56 AM Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > > Karl Fogel <kfo...@red-bean.com> writes: > > > 1) Make pristine text-base files optional. See issue #525 for > > details. In summary: currently, every large file uses twice the > > storage on the client side, and yet for most of these files > > there's little benefit. They're usually not plaintext, so 'svn > > diff' against the pristine base is pointless (unless you have some > > specialized diff tool for the particular binary format, but that's > > rare), and 'svn commit' likewise just sends up the whole working > > file. The only thing a local base gets you is local 'svn revert', > > which can be nice, but many of us would happily give it up for > > large files to avoid the 2x local storage cost. > > A proof-of-concept implementation of one possible approach for making > the text-bases optional is available on the branch: > > https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand > > While still being rough on the edges, it passes the whole test suite in > my environment and seems to work quite well in practice. > > A few notes on the current state: > > - The implementation includes a bump of the working copy format. > > - Although this would most certainly have to change in the future, for now > any working copy of the new format is considered to always have optional > text-bases (for easier testing, etc.). > > - There is no UI and no configuration yet, just the first cut of the core > part. > > The core idea is that we maintain the following invariant: only the modified > files have their pristine text-base files available on the disk. > > - To avoid having to access the text-base, the "is the file modified?" check > is performed by calculating the checksum of a file and comparing that to > what's recorded in the working copy. > > - A text-base of the unmodified file is the file itself, appropriately > detranslated. > > - To get into the appropriate state at the beginning of the operation, we walk > through the current text-base info in the db and check if the corresponding > working files are modified. The missing text-bases are fetched using the > svn_ra layer. The operations also include a final step during which the > no longer required text-bases are removed from disk. > > - The operations that don't need to access the text-bases (such as "svn ls" > or the updated "svn st") do not perform this walk and do not synchronize > the text-base state.
Thanks for working on this .. a couple questions: Suppose I am using this feature for binaries, which I think is the main use case. Using whatever tool I produce a modified version of my binary file. At this point in time, there is nothing in the text-base because I have not done any SVN operations other than checkout. Since it is a binary, other than maybe running status my next likely command is going to be commit. Are you saying that during the processing of this commit the client will first fetch the original text base from the server before doing the commit? That seems sub-optimal. Perhaps you are only doing this for diff or revert which would make perfect sense? Aside from all of that ... do the text bases get cleaned up? For example at the end of a successful commit does it get rid of that text base that no longer are current? Mark
