Thus said John Found on Tue, 20 Dec 2016 21:35:44 +0200: > For example, I can't see what is the problem to make diff of binary > files. As a result one will have the bytes that have to be > inserted/deleted from the first file in order to turn it into the > second. (Or I am wrong and that is why I ask such vague questions).
It certainly is possible, though not currently implemented as far as I know. The binary diff can be described simply as the deltas required to get from A to B. You might experiment with the following test commands: test-delta test-delta-analyze test-delta-apply test-delta-create It would seem that what you're asking for is a binary patch that perhaps takes advantage of the delta encoding algorithm? This would certainly require a special binary that understands the format of the data, but I don't see why this shouldn't be possible. I believe Fossil stores the baseline and deltas going back in time, so to open the most recent version of a file, it just gets the latest artifact, but to get older versions, it has to apply deltas. Perhaps the following will address some of your questions: http://www.fossil-scm.org/index.html/doc/trunk/www/delta_format.wiki http://www.fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.wiki http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki > Or what makes the 3-way merge algorithm not working on binary files. > The line organization of the text files? Something else? I'm not sure what it uses for binary files, but there is definitely a delta component being generated and stored. As a test, I added a large binary AVI to a fossil. Before: SIZE DATE FILE 217088 Dec 20 14:47 new.fossil 15155678 Dec 20 14:48 MVI_7509.AVI After: 15171584 Dec 20 14:48 new.fossil I then used vi to update a few bytes in the file and committed: 30117888 Dec 20 14:49 new.fossil It did double in size (not sure why, but I suspect it has something to do with establishing a baseline for the delta). But, I repeated the edit with vi and changed additional other bytes, but this time, it didn't grow very much at all: 30121984 Dec 20 14:50 new.fossil And again: 30130176 Dec 20 14:54 new.fossil So it is clearly efficiently storing them. Experimenting with the test-delta-create command, I get: 15155678 Dec 20 15:12 MVI_7509.AVI.first 15155695 Dec 20 15:13 MVI_7509.AVI.second $ fossil test-delta-create MVI_7509.AVI.first MVI_7509.AVI.second MVI_7509.AVI.delta 66 Dec 20 15:14 MVI_7509.AVI.delta So the delta is only 66 bytes: $ cat MVI_7509.AVI.delta up7k 3sQ@0,2:ab4yT@3sQ,4:zzjkf2@8pr,5:djfjkufdb@9Ut,5: fff 37s_Sf; Could I share this with someone? Sure. They could then use ``fossil test-delta-apply'' to use the ``patch.'' > What if I design some text file format (containing only ascii > characters) and it can't be properly processed by fossil? If it contains only ASCII characters then Fossil will have no problems handling it as a text file. It won't matter what arrangement of characters you place in such a file because they will be only ASCII. > Another example: Every binary file can be BASE64 encoded and it will > be turned into a valid text file. Fossil will not detect it as a > binary. But whether this file will be processed properly on diffs and > merges? Sure, you'll get an ASCII diff of the file, but it won't really mean much to describe the BASE64 diff between two files, however, if that's what you want, commit all binaries as BASE64 encoded files. Then you'll have to BASE64 decode the file as part of your ``build'' process, and you can even send patches/diffs of them. Andy -- TAI64 timestamp: 400000005859adef _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
