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

[Thornley, David]

> -----Original Message-----
> From: Jeff King [mailto:address@hidden
> Sent: Wednesday, July 11, 2001 1:29 PM
> To: address@hidden
> Subject: RE: How well does CVS handle other types of data?
> 
> 
> > From: address@hidden 
> [mailto:address@hidden Behalf Of
> > Thornley, David
> > Sent: Wednesday, July 11, 2001 12:35 PM
> > To: address@hidden
> > Subject: RE: How well does CVS handle other types of data?
> > Why?  It may make sense to you, with your applications, but I don't
> > see that it makes sense for mine.  I would rather group conceptually
> > related files together rather than files of the same datatype.
> 
> Exactly. "Source code" and "binary data" are quite 
> conceptually different.
> 
Really?  Suppose I'm putting a web site under CVS control.  I have HTML
and PNG files, let us say. What's the conceptual difference here?  Both
are part of the web site, both require some sort of tool to change (but
a different sort of tool), both exist in different versions.  There are
things I can do with one but not the other, but that's not much of a
conceptual difference.

> > So, given these constraints, what should I use?
> 
> A CVS repository for source code and a network directory for 
> binary data
> with an established, enforced naming and access procedure.
> 
That's worse than what I've got now.  Right now, the binary files
are tagged along with the text files, so I can easily pull out a
consistent set of files.  I don't think I should go for something
worse.  CVS with -kb does as good a job of managing binary data as
dated tarballs do - better, in fact, since it allows tagging and
retrieving without having to make sure the proper directory name
is in the proper version.

It doesn't offer nearly the advantages that it offers for text files,
but that's hardly a reason to not use it on binary files.

> > And the version control system that allows branching and makes it
> > relatively painless to merge binary files that get changed 
> in a merge
> > would be....
> 
> That depends on the filetype. Merging Word files is easy, as 
> it's simply a
> binary format for text. But how exactly would you merge a 
> JPEG? It doesn't
> make sense.
> 
Right.  It doesn't make sense.

So, what version control system handles binary files better than
CVS?  This is a serious question.  CVS satisfies my needs better
than any other VCS for source code (my needs here do include money;
CVS is much less expensive than ClearCase).  Is there another VCS
that works better than CVS for binary files, and, if so, how much
better?

CVS does everything for binary files that it does for text files,
except for merging and diffing.  If there is a VCS that will do
automatic merging and diffing for binary files, then that would
be a reason to use that instead of CVS.  If not, I have no idea
why I wouldn't want to use CVS.

> > We've got to have branching.  We can put up with a certain amount of
> > pain with merging if we have to.  I think CVS does the best possible
> > thing here.
> 
> I agree, assuming we're talking about datatypes that can be 
> automatically
> merged with a reasonable process.
> 
I think CVS does the best possible thing on binary files, also.  It isn't
as good a thing as it does with source files, but I don't know what tool
can be used to do automatic merging of PNGs, and therefore I don't know
that any tool can do better than CVS, hence I think CVS does the best
possible thing here also.

If you disagree, please nominate an action for "best thing" that is
better than what CVS does.

> > Consider a GIF that is changed on a branch and (in a 
> different manner)
> > the main trunk.  Where is the tool that will merge it like 
> CVS merges
> > text files?  Does it also work with PNGs and JPEGs?  Any 
> other binary
> > files we're likely to need?  If you know of such a tool, I want to
> > find out about it.
> 
> This makes no sense.

Right.  If I take the idea that there are better tools for binary files
than CVS, since CVS merges text files automatically, I am pretty much
forced to the conclusion that some tool merges binary files automatically.
This makes no sense.  Hence, by the contrapositive, the argument that
CVS is not the proper tool for binary files since it cannot merge them
makes no sense.

That's logic for you (particularly, it would seem, according to the
Humpty-Dumpty definition).

 Supposed you have a blank bitmap for a 
> "tools" icon.
> Two people make concurrent changes to it: the first person 
> draws a hammer,
> the second person draws a screwdriver. How could this be 
> merged? You don't
> want some weird hammer-screwdriver hybrid. You need to 
> manually choose which
> version to use.

Completely correct, with the caveat that you might find it
more desirable to make a new symbol.  It might be a hammer and
screwdriver combined, but it would be a new symbol.

 This is why having a separate, manually 
> controlled directory
> structure for binary data is the best solution.
> 
And here is where the logic falls down.  CVS maintains different
versions of the binary files.  It doesn't make the best possible use
of disk space in doing so, but who cares?  I can easily get
whatever version I like out of CVS and check it in as a result of
the merge.

Why is it somehow better to do all of this manually?  What do I
gain by doing all the work myself, and likely making mistakes?
If I wanted to screw things up I wouldn't use CVS in the first place.

I know that CVS works better on text files than binary files. 
That does not mean it's useless for binary files.
 
> > And a lame script will make merging GIFs easy?  You're not 
> making sense
> > here.
> 
> No, the concept of merging GIFs at all is what's not making sense.
> 
Right.  Since no tool merges GIFs, you can't fault CVS for not
merging GIFs.  So why not use CVS, when no other tool does better?