RE: binary files bad idea? why?

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Friday, July 2, 2004 at 12:34:42 (-0700), Paul Sander wrote: ]
>> Subject: RE: binary files bad idea? why?
>>
>> >--- 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.

>I thought we had agreed a half dozen years ago ore more that the
>definition of "binary file" as the phrase is usually used in this forum
>means "binary opaque file".  I thought you'd at least account for this
>interpretation if I used double quotes, but clearly you'd rather debate
>meaningless nonsense regardless.

I recall no such agreement.  I do agree a fair amount of discussion that
makes the distinction between mergeable content and non-mergeable content,
where it was agreed that there was a high degree of correlation between
binary files and non-mergeable content, but there was also wide
acknowledgement that text-based content can be non-mergeable (e.g.
uuencoded binaries), and that binary content can be mergeable (e.g.
mark-up formats like MS Word).

If you can come up with a time frame and subject thread in which such
agreement was made, then I'll be happy to review the entire discussion and
debate its merits.

>I.e. it is not possible, by definition, to resolve merge conflicts in
>any ``binary'' file.  Period.

If the ``binary'' file is truly opaque, which is to say that you have no
knowledge of its structure and can't find a tool that does, then I agree
that a merge conflicts are impossible to resolve.  However, not all binary
files have opaque structure, and I maintain that it is indeed possible
to resolve merge conflicts if you know something about their content.

While researching your claim of an agreement, I discovered the following:

> From:         Greg A. Woods
> Subject:      RE: cvs update; merge
> Date:         Wed, 29 Aug 2001 16:55:01 -0400 (EDT)

[...]

> Non-mergable files can NEVER be easily and generically handled by CVS as
> it stands today.  Until someone provides working code that makes the
> diff/diff3 toolset used internally in CVS (and RCS) to be replacable
> (preferably on a per-revision basis!!!!), there's no point to even
> pretending that presently non-mergable files can be handled generically
> by CVS.  (Of course with a selectable diff/diff3 algorithm you can treat
> truly binary-opaque files with a "copy-to-merge" mechanism, though even
> that's hardly 100% satisfactory.)

> As for "binary" from the fopen(3) perspective of stilly petty OS
> differences in EOL and EOF conventions, well since CVS cannot really
> properly support non-mergable binary files the only correct thing to do
> is to always treat all files as "text" files and to always apply the
> local libc fopen(foo, "*t") conversions for the given client platform
> (i.e. to always normalize the text stored in the repository into the
> Unix/ANSI/ISO-C standard format where "binary" == "text" and EOL is '\n'
> and there is no EOF character).

> [...]

Your first sentence in this quote says it all.  The code you suggested
in the second sentence was posted to this forum just three weeks later.
Taking that paragraph in its entirety, it seems almost as if we're in
violent agreement.

As for the second paragraph, the requirement here is that RCS and CVS
faithfully reproduce the version in a way that makes sense for the platform
on which the merge tool runs.  That means that for text files, the newline
conventions must be matched; binary files must not be modified in any way.
That problem is already solved, thanks to the RCS keyword expansion
capability.  After the versions are properly reproduced, the selected merge
tool can open the file in any way it deems appropriate.

BTW, the removed context of the quotation above has to do with cvswrappers,
and the appropriateness of marshalling aggregate data structures in the
filesystem in a CVS environment.  While that is worthy of further discussion,
it's not relevant to this thread.

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