[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How well does CVS handle other types of data?

From: Eric Siegerman
Subject: Re: How well does CVS handle other types of data?
Date: Thu, 12 Jul 2001 13:25:21 -0400
User-agent: Mutt/1.2.5i

On Wed, Jul 11, 2001 at 03:42:20PM -0400, Jeff King wrote:
> > -----Original Message-----
> > From: address@hidden [mailto:address@hidden Behalf Of
> > Mike Castle
> > Sent: Wednesday, July 11, 2001 2:56 PM
> > To: address@hidden
> > Subject: Re: How well does CVS handle other types of data?
> >
> >
> > On Wed, Jul 11, 2001 at 02:29:08PM -0400, Jeff King wrote:
> > > Exactly. "Source code" and "binary data" are quite conceptually
> > > different.

The two are completely orthogonal.  The opposite of "source code"
is "object code".  The opposite of "binary data" is "text data".
The historical accident that source code was typically text, and
object code typically binary, has led people to conflate the
concepts, saying "binary" when they mean "object" for example.

> > Not always.
> >
> > Both can be used to create an executable (embedded icons, for instance).
> > So, from the viewpoint of "source items that are used to make a final
> > executable," they ARE conceptually the same.
> No, they are still not the same at all.

Whether they're the same depends on which axis of difference
you're talking about.

If the question is "is this file intended to be readable by
humans; can I work with it in a text editor, and use diff and
patch to merge changes?", then text and binary files are of
course very different.

If the question is "does this file contain machine instructions
(or get transformed into machine instructions), or instructions
for some interpreter, or not?", well, that pretty much defines
the difference between "code" and "data".  That seems to be the
basis for the following:

> Icons are simply data being
> displayed by the window. The fact that it's compiled into the EXE is a build
> issue, not a source code issue. Embedding icons (e.g., Delphi copies the
> binary data into its form files) is just an issue of mixing data and code,
> which I consider bad regardless of versioning tool.

But, as you say, it's a distinction that's completely irrelevent
to CVS -- and thus to this forum.

But if the question is, "is the file human-generated or
machine-generated?", the implication being that the former should
be revision-controlled and the latter typically not, then there's
NO difference between source whose form is text and source whose
form is binary.

If people were careful to say "object" when they meant
"machine-generated", and "binary" *only* when they meant "not
vi-editable, diff'able, or patch'able", there would be a lot
fewer misunderstandings and flamewars on this list.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]