cannot compute difference between binary files
(1) By anonymous on 2020-08-20 15:52:12 [link] [source]
comparison in timeline
When doing a comparison in timeline then text files are nicely compared and differences are shown.
Trying to do so with binary files just nothing is done.
I understand that it is not the same but my question is:
- Why can not even the file sizes be compared (greater, equal, smaller)?
- and equality on content could also be tested (same or different)
fossil status
- Why can not even the file sizes be compared (and shown in num bytes)?
- and equality could also be tested (same or different)
- in local checkout the mtimes could also be compared (older, same, newer)
This is my first post into this forum and I hope that my feature request will be understood and soon come to an improvement, which I miss on my dayly work with fossil, which is a really great tool ! (I am using it mainly on windows but also on linux)
Regards MBL
(2) By Stephan Beal (stephan) on 2020-08-21 00:54:33 in reply to 1 [link] [source]
When doing a comparison in timeline then text files are nicely compared and differences are shown.
Trying to do so with binary files just nothing is done.
We cannot display diffs of binary files in any sensible way. Fossil does, however, tell you when two binary files differ.
I understand that it is not the same but my question is:
Why can not even the file sizes be compared (greater, equal, smaller)? and equality on content could also be tested (same or different)
i'm not clear on what you're asking. Fossil shows you that the two files differ, and that's all it can really say to you about them. If their sizes differ then the content necessarily differs. It's possible for them to differ and be the same size. Having the size of each binary in the fossil UI would not seem to add anything other than noise. It's not information a user can act upon.
fossil status
Why can not even the file sizes be compared (and shown in num bytes)?
and equality could also be tested (same or different)
i'm not sure what you're asking. Again, the file sizes are not important information for knowing whether a file has a difference. It either differs or it does not, depending on the hash value of its contents. If they match, it's not different. If they don't, it's different.
If fossil status says a file is modified, it means the hash value of its contents differ from what is stored in the repository. If you want to see exactly how it differs, use "fossil diff" or "fossil gdiff", and gdiff appears to be able to accept binary files for cases where an external graphical diff can make some use of them (see the --diff-binary flag, but note that it's only useful if your external diff program supports binary inputs).
in local checkout the mtimes could also be compared (older, same, newer)
File times are not relevant for fossil's understanding of "is modified." The only value it considers is the hash code of the file's contents. Fossil does not track any file times: all files within a single commit have the timestamp of that commit. When fossil calculates a timestamp for a file (e.g. for the "touch" command) it uses the timestamp of the most recent commit in which that file was modified or added.
(3.2) By MBL (RoboManni) on 2020-08-23 12:51:31 edited from 3.1 in reply to 2 [source]
in timeline comparison
I fully understand that binary differences are not visualized by fossil itself (and on command line it would be possible already with gdiff in an external tool like WinMerge) but the binary sizes of the two artifacts could be shown.
If this would be too time consuming due to not stored info, then maybe only on demand (with a click on VIEW button)? This could become visible at the time when the user really needs. Maybe this could be configured also as a configurable timeline behaviour option; how to display binary differences.
Such a VIEW button or preferred a timeline option would only have to combine what could be done in several steps otherwise. The timeline comparison shows for example
Modified xyz.exe from [b4b0a38382] to [58cf91937f] connot compute difference between binary files
but going for each of these two artifact links into a separete browser window you can see in each
- the time of when each side of the "impossible" comparison was checkedin
- with a message like "file is 1828352 bytes of binary data" the size.
Artifact b4b0a38382.. part of checkin [3005..] at 2018-07-30 12:39:13 .. file is 1828352 bytes of binary data
and
Artifact 58cf91937f.. part of checkin [de5b..] at 2019-11-07 17:49:04 .. file is 1957376 bytes of binary data
It means all information is available in 3 places already but NOT in 1 place for easy comparison, in the timeline when asking for comparison. (I am using fossil 2.12.1)
with fossil status -v
In local fossil checkout file FOSSIL rsp. .fslckout in table vfile there is a column mtime beside each pathname of file which belongs to the current checkout; aren't these the file date and time stamps?... good to become compared to find changes which should be checked in?
But even if these are the checkin times, they can become the same as the local time stamps with "fossil update --setmtime". Then they are the same like their checkin times ... but neverlesess, this mtime column matches local file date time when there is no difference between checkout and user possibility to have this file edited and changed in content/size/datetime. After having done such a change, eg by use of an editor, I only would like to see in the fossil status list these mtime stamps compared with the current existing file timestamp, which the dir or ls command also would show.
If not as a standard then I suggest the -v rsp. --verbose command line option to make information from the local file storage system visible in addition.
My dream here would be to have the FOSSIL contained mtime (time from checkin, checkout or now; see also the fossil touch command with option --now, --checkin or --checkout) with the current time from the file system (like with ls or dir command of the command shell).
I hope you understand that my requests are not too much new but would help me and other users as well. Time stamps are also very important meta information for me; and they are already available but not visible in an easy way.
Thanks and regards MBL