RE: binary files bad idea? why?

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>It is literally _impossible_ to manually resolve (with any degree of
>correctness) any three way merge with conflicts in any ``binary'' file,
>regardless of whether it has been encoded as text or not.

It IS possible, using a tools that understand the content of the file.
Data that contain record or linked structures can be merged, regardless
of whether they live in memory or in files.  The catch is that a
specialized merge tool is needed, which doesn't happen to be based on
the generic Unix diff tools.

Consider the following hypothetical case:  A threaded data structure
is marshalled into a line-based textual format.  You could theoretically
use diff3 to perform a 3-way merge on the data, but then the result must
be inspected and the links properly reconnected by hand.  After sufficient
user outcry, the vendor supplies validity checker that users can run
after they complete their manual merges.  Of course, the users complain
that the checker isn't sufficient, so the vendor supplies a merge tool
that produces usable output.  Finally, the users are happy.

Now consider that same case, except that the file format isn't a line-based
textual format, but is instead a binary format that is less expensive to
produce and consume.  There's no practical difference, despite the fact
that one file is binary, and the other is not.

This situation occurs in real life.  Frame Maker is my canonical example,
because it truly does have semantically equivalent binary and text-based
file formats.  And there are others.

>(Even without concurrency there's still the issue of merging changes
>between branches.)

>(Yes conflicts can be ``resolved'' by choosing one or the other, but
>that's a special case, and a hack, not the general case.)

Actually, it's the most general case (it will work with ANY form of data),
but it's also the choice of last resort because it offers the least control
over the result.  (Splitting hairs here.)

>--- End of forwarded message from address@hidden