On Dec 20, 2016, at 10:59 PM, John Found <johnfo...@asm32.info> wrote: > > Well, the compression is the last thing I am talking about. It is important, > but not essential.
Then you’re missing the point I’m bringing up by talking about compression. If you check a file into Fossil that has a format where a change of a dozen bits in a 23 kB file can cause 28 kB of differences in the repository, you cannot expect Fossil to do diffs and merges and such, because to a first approximation, the whole file changes on every checkin from Fossil’s perspective. The only solution to this would be to build knowledge of PNG and such into Fossil so that it could decompress the input files, *then* do its normal delta compression, merging, etc. That is entirely do-able, but it means you must give Fossil internal knowledge of all the weird binary file formats for which you wish it to be able to produce diffs, where it would fail without that knowledge. The alternative, if you have multiple people editing a bitmap file, is to use a file format like Windows BMP, where Fossil sees the raw bitmap data directly, so that it *can* do merges and such automatically, without special knowledge of the file format. > I am talking about several people working on one file and then fossil merging > the changes automatically (of course if there is no conflicts in the edits). That is exactly what I’m talking about in my BMP vs PNG examples. If you wish to discuss a different file type than than bitmap graphics, give your own example. Until then, mine is the only concrete example we have available to discuss. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
