I am not talking about the fossil heuristics in detection of what file is binary and what file is text. Imagine all detection is switched off.
Under "fossil algorithms" I mean two (in my understanding most important in what is called "version control": diff algorithm and 3-way merge algorithm. 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). Or what makes the 3-way merge algorithm not working on binary files. The line organization of the text files? Something else? What if I design some text file format (containing only ascii characters) and it can't be properly processed by fossil? 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? Probably not. But why? On Tue, 20 Dec 2016 12:13:43 -0700 Warren Young <[email protected]> wrote: > On Dec 20, 2016, at 11:48 AM, John Found <[email protected]> wrote: > > > > I know that fossil (and most other version control systems) can handle > > properly > > only text source files. > > Says who? > > There are some features of Fossil that simply don’t work when given a binary > file, like “fossil diff,” but if you think this is a missing feature (or even > a bug!) I’d have to ask how you think it should work? > > Consider the case of a PNG. How would you expect “fossil diff” to show the > difference between two PNGs? > > Now multiply by the number of other binary file formats. > > It is also the case that checking in compressed binary files is generally a > mistake, since that will largely defeat the built-in diffing and compression > mechanisms in Fossil, bloating the repository on every checkin. > > (For some use cases, you can now avoid this problem with the new unversioned > files feature.) > > Both of those classes of problem aside, Fossil will certainly accept “binary” > files. > > > What makes the binary files different from the text files? The presence or > > absence of > > 0 bytes does not seems to make serious difference for processing by the > > same algorithms. > > Fossil uses a heuristic to decide if a given file is “binary” or not, and it > has more to do with the chance that it will display properly when served to a > web browser than anything else. > > Because it is a heuristic, it is possible to trick it. For example, very > long text lines may be misdetected as a “binary” file, because it runs out of > buffer space looking for the first line terminator. > > > What properties a file format needs in order to be processed properly by > > fossil? > > Give a specific use case. The answer differs depending on what Fossil > commands you want to be able to use on the files you check in. > > I gave the “diff” case above, but that is not the only command that changes > behavior depending on whether the binary file heuristic decides that the file > is “binary.” > > I’m putting “binary” in quotes because it is not a clear-cut distinction. > For Fossil’s purposes, an uncompressed TIFF is “less binary” than a PNG file, > because it is possible to do useful levels of delta compression on the TIFF > but not on the PNG. > > > Is it enough for a file to contains only utf-8 characters or some other > > properties are > > mandatory as well? > > If you want to know the heuristic’s current implementation details, study > looks_like_utf8() in src/lookslike.c. > > (There is also a UTF-16 version of that function, typically needed on > Windows.) > > > Is it possible to define such binary file format that to be properly > > processed > > by fossil (of course, after removing the explicit binary file checks)? > > > > Or the opposite question: Is it possible to compose such text file that to > > not be > > processed properly by fossil algorithms? > > Both questions should be answered by a study of that heuristic function. > > If you have further questions, make your questions more specific. Your > current questions are so vague that I can give the answer “Yes” to both, and > be correct. Not useful, I realize, but correct. :) > _______________________________________________ -- http://fresh.flatassembler.net http://asm32.info John Found <[email protected]> _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
