On Sat, Apr 25, 2020 at 2:18 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> Mark Phippard wrote on Sat, 25 Apr 2020 18:01 +00:00: > > 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 > > Does #4 apply to commits, updates, or both? > I would say both. > what is a large binary file that shouldn't be deltified? > > is the important question here. The idea is to have reasonable default > behaviour out of the box, without adding mandatory configuration knobs. In reference to Brane's question ... I agree doing it automatically would be better. I would be +1 if someone figured out a good way. It seems like getting the plumbing in place would be a good first step though. IMO, the complications are: 1. Not storing the pristine seems at least mildly controversial to do automatically depending on one's workflow. I could always live with it, but I almost always work while attached to a network. Perhaps this could just be a local conf file option that applied to all binary files .. maybe with a corresponding svn:xxx property that overrides the conf file? 2. Trying to identify a specific subset of binary files that need these features seems hard. There are past threads of people talking about how some large binaries do compress well, such as certain types of tar files. Personally, I suspect binaries that compress well is rare. Maybe if these features could be implemented we should just flip this around and make these new behaviors the default for all binary files and require a property or setting for the exceptions? Anyway, it seems premature to discuss this in too much depth unless someone thinks writing this code would be straightforward. I assume it must not be, and as I mentioned earlier, unfortunately I am not prepared to be able to offer any help. My sense, with no hard data to back this up, is that the CollabNet customers I am aware of that are sticking with SVN are doing so because it already handles large files and large repositories better than git, plus for some of them it offers locking workflow which is useful for binary files. I suspect if SVN were to get even stronger in this area it would cement this as a viable niche where SVN remains the best tool for their needs. -- Thanks Mark Phippard
