On 25 Apr 2020, Mark Phippard wrote: >On Sat, Apr 25, 2020 at 1:54 PM Johan Corveleyn <jcor...@gmail.com> >wrote: > >While hand-waving on all of the details, it seems like if we had some >property one could put on a file that combined all of these concepts >we could have a really compelling solution for handling large >binaries.
(At a certain point this discussion should start happening on dev@, probably.) Obviously, the UI by which one accesses this proposed new feature is separate from how the feature is implemented under the hood. Given that keeping or not keeping text bases is a purely client-side concern, properties shouldn't be the only UI gateway to this feature. It's even more important to offer client-side *configuration* to be able to say things like: * Files larger than size X don't keep a text base * Files of mime-type BLAH don't keep a text base * Files with at least one property from [some set of arbitrary properties] don't keep a text base * ...etc. The key thing is that the client decides, since this is purely a client-side decision about trading off between local storage cost and network turnarounds for diff and revert. >I am not sure Karl's use case but I know video game >companies have raised the issue in the past, and I know some of our >customers deal with things like large binary files for embedded chip >designs etc. The use case I have in mind is exactly that one: checking out files that are both large and non-mergeable anyway (luckily, these two things tend to go together). >But the final goal should be something like this (in order of >importance): > >1. Do not store a pristine in working copy for the file >2. Do not do deltification on the client when committing >3. Do not do compression on server when storing >4. Do not do deltification on server If (1), then (2) is implied (unless by "deltification" you just mean "compression without reference to any pristine text base"). (3) and (4) are a separate project IMHO. They're interesting ideas & worth pursuing, but they have no effect on client side storage and are thus outside the scope of what I was proposing FWIW. Best regards, -Karl
